draft-ietf-sigtran-rfc3332bis-00.txt   draft-ietf-sigtran-rfc3332bis-01.txt 
Network Working Group Ken Morneault Network Working Group K. Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Expires: January 2004 Expires: March 29, 2004
Javier Pastor-Balbßs J. Pastor-Balbas
Ericsson Ericsson
July, 2004 September 30, 2004
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA) User Adaptation Layer (M3UA)
<draft-ietf-sigtran-rfc3332bis-00.txt> <draft-ietf-sigtran-rfc3332bis-01.txt>
Status of this memo STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author certifies that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which they are aware have
been disclosed, and any of which they become aware will be disclosed,
in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.This document is an Internet-Draft and
is in full conformance with all provisions of Section 10 of RFC2026.
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo defines a protocol for supporting the transport of any SS7 This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol. Also, services of the Stream Control Transmission Protocol. Also,
provision is made for protocol elements that enable a seamless provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database, or between two Gateway Controller (MGC) or IP-resident Database, or between two
IP-based applications. It is assumed that the SG receives SS7 IP-based applications. It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message signalling over a standard SS7 interface using the SS7 Message
Transfer Part (MTP) to provide transport. Transfer Part (MTP) to provide transport.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.......................................................5 1. Introduction.....................................................5
1.1 Scope..............................................................5 1.1 Scope............................................................5
1.2 Terminology........................................................5 1.2 Terminology......................................................5
1.3 M3UA Overview......................................................7 1.3 M3UA Overview....................................................7
1.4 Functional Areas..................................................11 1.4 Functional Areas................................................11
1.5 Sample Configuration..............................................18 1.5 Sample Configuration............................................18
1.6 Definition of M3UA Boundaries.....................................20 1.6 Definition of M3UA Boundaries...................................20
2. Conventions........................................................24 2. Conventions......................................................24
3. M3UA Protocol Elements.............................................24 3. M3UA Protocol Elements...........................................24
3.1 Common Message Header.............................................25 3.1 Common Message Header...........................................25
3.2 Variable Length Parameter Format..................................27 3.2 Variable Length Parameter Format................................27
3.3 Transfer Messages.................................................29 3.3 Transfer Messages...............................................29
3.4 SS7 Signalling Network Management (SSNM) Messages.................32 3.4 SS7 Signalling Network Management (SSNM) Messages...............32
3.5 ASP State Maintenance (ASPSM) Messages............................41 3.5 ASP State Maintenance (ASPSM) Messages..........................41
3.6 Routing Key Management (RKM) Messages [Optional]..................44 3.6 Routing Key Management (RKM) Messages [Optional]................44
3.7 ASP Traffic Maintenance (ASPTM) Messages..........................52 3.7 ASP Traffic Maintenance (ASPTM) Messages........................52
3.8 Management (MGMT) Messages.......................................57 3.8 Management (MGMT) Messages.....................................57
4. Procedures.........................................................62 4. Procedures.......................................................62
4.1 Procedures to Support the M3UA-User...............................62 4.1 Procedures to Support the M3UA-User.............................62
4.2 Receipt of Primitives from the Layer Management...................63 4.2 Receipt of Primitives from the Layer Management.................63
4.3 AS and ASP State Maintenance......................................65 4.3 AS and ASP/IPSP State Maintenance...............................65
4.4 Routing Key Management Procedures [Optional]......................80 4.4 Routing Key Management Procedures [Optional]....................81
4.5 Procedures to Support the Availability or Congestion Status of SS7 4.5 Procedures to Support the Availability or Congestion Status of
Destination.......................................................83 SS7 Destination.................................................84
4.6 MTP3 Restart......................................................86 4.6 MTP3 Restart....................................................86
4.7 NIF not Available.................................................87 4.7 NIF not Available...............................................87
4.8 M3UA Version Control..............................................87 4.8 M3UA Version Control............................................88
5. Examples of M3UA Procedures........................................87 4.9 M3UA Termination................................................88
5.1 Establishment of Association and Traffic between SGPs and ASPs....87 5. Examples of M3UA Procedures......................................88
5.2 ASP Traffic Failover Examples.....................................93 5.1 Establishment of Association and Traffic between SGPs and ASPs..88
5.3 Normal Withdrawal of an ASP from an Application Server............94 5.2 ASP Traffic Failover Examples...................................94
5.4 Auditing examples.................................................95 5.3 Normal Withdrawal of an ASP from an Application Server..........95
5.5 M3UA/MTP3-User Boundary Examples..................................95 5.4 Auditing examples...............................................96
5.6 Examples for IPSP communication...................................99 5.5 M3UA/MTP3-User Boundary Examples................................96
6. Security Considerations...........................................100 5.6 Examples for IPSP communication................................100
6.1 Introduction.....................................................100 6. Security Considerations.........................................101
6.2 Threats..........................................................101 6.1 Introduction...................................................101
6.3 Protecting Confidentiality.......................................101 6.2 Threats........................................................102
7. IANA Considerations...............................................101 6.3 Protecting Confidentiality.....................................102
7.1 SCTP Payload Protocol Identifier.................................101 7. IANA Considerations.............................................102
7.2 M3UA Port Number.................................................102 7.1 SCTP Payload Protocol Identifier...............................102
7.3 M3UA Protocol Extensions.........................................102 7.2 M3UA Port Number...............................................103
8. References........................................................103 7.3 M3UA Protocol Extensions.......................................103
8.1 Normative References.............................................103 8. References......................................................104
8.2 Informative References...........................................104 8.1 Normative References...........................................104
9. Acknowledgements..................................................105 8.2 Informative References.........................................105
10. Document Contributors............................................105 9. Acknowledgements................................................106
Appendix A...........................................................106 10. Document Contributors..........................................106
A.1 Signalling Network Architecture..................................106 Appendix A.........................................................108
A.1 Signalling Network Architecture................................108
A.2 Redundancy Models................................................108 A.2 Redundancy Models..............................................110
Appendix B: Changes from RFC3332.....................................109 Editors' Addresses.................................................113
Editors' Addresses...................................................110
1. Introduction 1. Introduction
This memo defines a protocol for supporting the transport of any SS7 This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol [17]. Also, services of the Stream Control Transmission Protocol [17]. Also,
provision is made for protocol elements that enable a seamless provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media protocol would be used between a Signalling Gateway (SG) and a Media
Gaway Controller (MGC) or IP-resident Database [11], or between two Gateway Controller (MGC) or IP-resident Database [11], or between two
IP-based applications. IP-based applications.
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling There is a need for Switched Circuit Network (SCN) signalling
protocol delivery from an SS7 Signalling Gateway (SG) to a Media protocol delivery from an SS7 Signalling Gateway (SG) to a Media
Gateway Controller (MGC) or IP-resident Database as described in the Gateway Controller (MGC) or IP-resident Database as described in the
Framework Architecture for Signalling Transport [11]. The delivery Framework Architecture for Signalling Transport [11]. The delivery
mechanism should meet the following criteria: mechanism should meet the following criteria:
skipping to change at page 5, line 45 skipping to change at page 5, line 45
In simplistic transport terms, the SG will terminate SS7 MTP2 and In simplistic transport terms, the SG will terminate SS7 MTP2 and
MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP and/or any other MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP and/or any other
MTP3-User protocol messages, as well as certain MTP network MTP3-User protocol messages, as well as certain MTP network
management events, over SCTP transport associations to MTP3-User management events, over SCTP transport associations to MTP3-User
peers in MGCs or IP-resident Databases. peers in MGCs or IP-resident Databases.
1.2 Terminology 1.2 Terminology
Application Server (AS) - A logical entity serving a specific Routing Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element Key. An example of an Application Server is a virtual switch element
handling all call processing for a set of trunks, identified by a handling all call processing for a signalling relation, identified by
SS7 DPC/OPC. Another example is a virtual database element, handling a SS7 DPC/OPC. Another example is a virtual database element,
all HLR transactions for a particular SS7 SIO/DPC/OPC combination. handling all HLR transactions for a particular SS7 SIO/DPC/OPC
The AS contains a set of one or more unique Application Server combination. The AS contains a set of one or more unique Application
Processes, of which one or more is normally actively processing Server Processes, of which one or more is normally actively processing
traffic. Note that there is a 1:1 relationship between an AS and a traffic. Note that there is a 1:1 relationship between an AS and a
Routing Key. Routing Key.
Application Server Process (ASP) - A process instance of an Application Server Process (ASP) - A process instance of an
Application Server. An Application Server Process serves as an active Application Server. An Application Server Process serves as an active
or backup process of an Application Server (e.g., part of a or backup process of an Application Server (e.g., part of a
distributed virtual switch or database). Examples of ASPs are distributed virtual switch or database). Examples of ASPs are
processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP
contains an SCTP endpoint and may be configured to process signalling contains an SCTP endpoint and may be configured to process signalling
traffic within more than one Application Server. traffic within more than one Application Server.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
carrier grade networks, using an MTP3 linkset or an equivalent, to carrier grade networks, using an MTP3 linkset or an equivalent, to
allow rerouting between the SGs in the event of route failures. Where allow rerouting between the SGs in the event of route failures. Where
SGPs are used, inter-SGP communication might be used. Inter-SGP SGPs are used, inter-SGP communication might be used. Inter-SGP
protocol is outside of the scope of this document. protocol is outside of the scope of this document.
The following example shows a signalling gateway partitioned into two The following example shows a signalling gateway partitioned into two
network appearances. network appearances.
SG SG
+-------+ +---------------+ +-------+ +---------------+
| SEP +--------------| SS7 Ntwk |M3UA| ---- | SEP +--------------| SS7 Ntwk.|M3UA| ----
+-------+ SS7 links | "A" | | / \ +-------+ SS7 links | "A" | | / \
|__________| +-----------+ ASPs | |__________| +-----------+ ASPs |
| | | \ / | | | \ /
+-------+ | SS7 Ntwk | | ---- +-------+ | SS7 Ntwk.| | ----
| SEP +--------------+ "B" | | | SEP +--------------+ "B" | |
+-------+ +---------------+ +-------+ +---------------+
Figure 2 Example with multiple Network Figure 2 Example with multiple Network
1.4.2 Routing Contexts and Routing Keys 1.4.2 Routing Contexts and Routing Keys
1.4.2.1 Overview 1.4.2.1 Overview
The distribution of SS7 messages between the SGP and the Application The distribution of SS7 messages between the SGP and the Application
skipping to change at page 15, line 10 skipping to change at page 15, line 10
is designed to provide an extension of the MTP3 defined user is designed to provide an extension of the MTP3 defined user
primitives. primitives.
1.4.3.1 Signalling Gateway SS7 Layers 1.4.3.1 Signalling Gateway SS7 Layers
The SG is responsible for terminating MTP Level 3 of the SS7 The SG is responsible for terminating MTP Level 3 of the SS7
protocol, and offering an IP-based extension to its users. protocol, and offering an IP-based extension to its users.
From an SS7 perspective, it is expected that the Signalling Gateway From an SS7 perspective, it is expected that the Signalling Gateway
transmits and receives SS7 Message Signalling Units (MSUs) over a transmits and receives SS7 Message Signalling Units (MSUs) over a
standard SS7 network interface, using the SS7 Message Transfer Part standard SS7 network interface, using the SS7 Message Transfer Part
(MTP) [7,8,9] to provide reliable transport of the messages. (MTP) [7,8,9].
As a standard SS7 network interface, the use of MTP Level 2 As a standard SS7 network interface, the use of MTP Level 2
signalling links is not the only possibility. ATM-based High Speed signalling links is not the only possibility. ATM-based High Speed
Links can also be used with the services of the Signalling ATM Links can also be used with the services of the Signalling ATM
Adaptation Layer (SAAL) [18,19]. Adaptation Layer (SAAL) [18,19].
Note: It is also possible for IP-based interfaces to be present, Note: It is also possible for IP-based interfaces to be present,
using the services of the MTP2-User Adaptation Layer (M2UA) [27] or using the services of the MTP2-User Adaptation Layer (M2UA) [27] or
M2PA [28]. M2PA [28].
skipping to change at page 16, line 33 skipping to change at page 16, line 33
All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
Routing Key at an SGP are mapped to an Application Server. Routing Key at an SGP are mapped to an Application Server.
The Application Server is the set of all ASPs associated with a The Application Server is the set of all ASPs associated with a
specific Routing Key. Each ASP in this set may be active, inactive or specific Routing Key. Each ASP in this set may be active, inactive or
unavailable. Active ASPs handle traffic; inactive ASPs might be used unavailable. Active ASPs handle traffic; inactive ASPs might be used
when active ASPs become unavailable. when active ASPs become unavailable.
The failover model supports an "n+k" redundancy model, where "n" ASPs The failover model supports an "n+k" redundancy model, where "n" ASPs
is the number of redundant ASPs required to handle traffic and "k" is the minimum number of redundant ASPs required to handle traffic and
ASPs are available to take over for a failed or unavailable ASP. "k" ASPs are available to take over for a failed or unavailable ASP.
Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be
either active at the same time as "n" or kept inactive until needed either active at the same time as "n" or kept inactive until needed
due to a failed or unavailable ASP. due to a failed or unavailable ASP.
A "1+1" active/backup redundancy is a subset of this model. A 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 ASP simplex "1+0" model is also supported as a subset, with no ASP
redundancy. redundancy.
1.4.5 Flow Control 1.4.5 Flow Control
skipping to change at page 17, line 36 skipping to change at page 17, line 36
1.4.7 SCTP Stream Mapping. 1.4.7 SCTP Stream Mapping.
The M3UA layer at both the SGP and ASP also supports the assignment The M3UA layer at both the SGP and ASP also supports the assignment
of signalling traffic into streams within an SCTP association. of signalling traffic into streams within an SCTP association.
Traffic that requires sequencing SHOULD be assigned to the same Traffic that requires sequencing SHOULD be assigned to the same
stream. To accomplish this, MTP3-User traffic may be assigned to stream. To accomplish this, MTP3-User traffic may be assigned to
individual streams based on, for example, the SLS value in the MTP3 individual streams based on, for example, the SLS value in the MTP3
Routing Label, subject of course to the maximum number of streams Routing Label, subject of course to the maximum number of streams
supported by the underlying SCTP association. supported by the underlying SCTP association.
The following rules MUST to be followed (see section 3.1.2): The following rules apply (see section 3.1.2):
1. DATA message MUST NOT be sent on stream 0. 1. DATA message MUST NOT be sent on stream 0.
2. ASPSM, MGMT, RKM classes SHOULD be sent on stream 0 (Other than 2. ASPSM, MGMT, RKM classes SHOULD be sent on stream 0 (Other than
BEAT, BEAT ACK and NTFY messages) BEAT, BEAT ACK and NTFY messages)
3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be 3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be
sent on any stream. sent on any stream.
1.4.8 SCTP Client/Server Model 1.4.8 SCTP Client/Server Model
It is recommended that the SGP and ASP be able to support both client It is recommended that the SGP and ASP be able to support both client
skipping to change at page 21, line 23 skipping to change at page 21, line 23
An example of the upper layer primitives provided by the SCTP are An example of the upper layer primitives provided by the SCTP are
provided in Reference [17] Section 10. provided in Reference [17] Section 10.
1.6.3 Definition of the Boundary between M3UA and Layer Management 1.6.3 Definition of the Boundary between M3UA and Layer Management
M-SCTP_ESTABLISH request M-SCTP_ESTABLISH request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to establish an SCTP association with its Purpose: LM requests ASP to establish an SCTP association with its
peer. peer.
M-STCP_ESTABLISH confirm M-SCTP_ESTABLISH confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP confirms to LM that it has established an SCTP Purpose: ASP confirms to LM that it has established an SCTP
association with its peer. association with its peer.
M-SCTP_ESTABLISH indication M-SCTP_ESTABLISH indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that a remote ASP has established an SCTP Purpose: M3UA informs LM that a remote ASP has established an SCTP
association. association.
M-SCTP_RELEASE request M-SCTP_RELEASE request
skipping to change at page 25, line 48 skipping to change at page 25, line 48
Message Class: 8 bits (unsigned integer) Message Class: 8 bits (unsigned integer)
The following list contains the valid Message Type Classes: The following list contains the valid Message Type Classes:
0 Management (MGMT) Messages 0 Management (MGMT) Messages
1 Transfer Messages 1 Transfer Messages
2 SS7 Signalling Network Management (SSNM) Messages 2 SS7 Signalling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages 3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved for Other Sigtran Adaptation Layers 5 Reserved for Other SIGTRAN Adaptation Layers
6 Reserved for Other Sigtran Adaptation Layers 6 Reserved for Other SIGTRAN Adaptation Layers
7 Reserved for Other Sigtran Adaptation Layers 7 Reserved for Other SIGTRAN Adaptation Layers
8 Reserved for Other Sigtran Adaptation Layers 8 Reserved for Other SIGTRAN Adaptation Layers
9 Routing Key Management (RKM) Messages 9 Routing Key Management (RKM) Messages
10 to 127 Reserved by the IETF 10 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions 128 to 255 Reserved for IETF-Defined Message Class extensions
Message Type: 8 bits (unsigned integer) Message Type: 8 bits (unsigned integer)
The following list contains the message types for the defined The following list contains the message types for the defined
messages. messages.
Management (MGMT) Messages (See Section 3.8) Management (MGMT) Messages (See Section 3.8)
skipping to change at page 30, line 43 skipping to change at page 30, line 43
context for the message and implicitly identifies the SS7 Point context for the message and implicitly identifies the SS7 Point
Code format used, the SS7 Network Indicator value, and the MTP3 Code format used, the SS7 Network Indicator value, and the MTP3
and possibly the MTP3-User protocol type/variant/version used and possibly the MTP3-User protocol type/variant/version used
within the specific SS7 network. Where a SG operates in the within the specific SS7 network. Where a SG operates in the
context of a single SS7 network, or individual SCTP associations context of a single SS7 network, or individual SCTP associations
are dedicated to each SS7 network context, the Network Appearance are dedicated to each SS7 network context, the Network Appearance
parameter is not required. In other cases the parameter may be parameter is not required. In other cases the parameter may be
configured to be present for the use of the receiver. configured to be present for the use of the receiver.
The Network Appearance parameter value is of local significance The Network Appearance parameter value is of local significance
only, coordinated between the SG and AS. Therefore, in the case only, coordinated between the SGP and ASP. Therefore, in the case
where an ASP is connected to more than one SGP, the same SS7 where an ASP is connected to more than one SGP, the same SS7
network context may be identified by different Network Appearance network context may be identified by different Network Appearance
values depending over which SGP a message is being transmitted/- values depending over which SGP a message is being transmitted/
received. received.
Where the optional Network Appearance parameter is present, it Where the optional Network Appearance parameter is present, it
MUST be the first parameter in the message as it defines the MUST be the first parameter in the message as it defines the
format of the Protocol Data field. format of the Protocol Data field.
IMPLEMENTATION NOTE: For simplicity of configuration it may be IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a desirable to use the same NA value across all nodes sharing a
particular network context. particular network context.
skipping to change at page 35, line 34 skipping to change at page 35, line 34
appearance is affected - this is used to indicate network appearance is affected - this is used to indicate network
isolation to the ASP. isolation to the ASP.
INFO String: variable length INFO String: variable length
The optional INFO String parameter can carry any meaningful UTF-8 The optional INFO String parameter can carry any meaningful UTF-8
[10] character string along with the message. Length of the INFO [10] character string along with the message. Length of the INFO
String parameter is from 0 to 255 octets. No procedures are String parameter is from 0 to 255 octets. No procedures are
presently identified for its use but the INFO String MAY be used presently identified for its use but the INFO String MAY be used
for debugging purposes. An INFO String with a zero length for debugging purposes. An INFO String with a zero length
parameter is not considered as an error (this means that the parameter is not considered as an error (A zero length parameter is
Length field in the TLV will be set to 4). one in which the Length field in the TLV will be set to 4).
3.4.2 Destination Available (DAVA) 3.4.2 Destination Available (DAVA)
The DAVA message is sent from an SGP to all concerned ASPs to The DAVA message is sent from an SGP to all concerned ASPs to
indicate that the SG has determined that one or more SS7 destinations indicate that the SG has determined that one or more SS7 destinations
are now reachable (and not restricted), or in response to a DAUD are now reachable (and not restricted), or in response to a DAUD
message if appropriate. If the ASP M3UA layer previously had no message if appropriate. If the ASP M3UA layer previously had no
routes to the affected destinations the ASP MTP3-User protocol is routes to the affected destinations the ASP MTP3-User protocol is
informed and may now resume traffic to the affected destination. The informed and may now resume traffic to the affected destination. The
ASP M3UA layer now routes the MTP3-user traffic through the SG ASP M3UA layer now routes the MTP3-user traffic through the SG
skipping to change at page 36, line 24 skipping to change at page 36, line 24
The DAUD message contains the following parameters: The DAUD message contains the following parameters:
Network Appearance Conditional Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
Affected Point Code Mandatory Affected Point Code Mandatory
INFO String Optional INFO String Optional
The format and description of DAUD Message parameters is the same as The format and description of DAUD Message parameters is the same as
for the DUNA message (See Section 3.4.1). for the DUNA message (See Section 3.4.1).
It is recommended that during normal operation (traffic handling) the
mask field of the Affected Point Code parameter in the DAUD message is
kept to a zero value in order to avoid SG overloading.
3.4.4 Signalling Congestion (SCON) 3.4.4 Signalling Congestion (SCON)
The SCON message can be sent from an SGP to all concerned ASPs to The SCON message can be sent from an SGP to all concerned ASPs to
indicate that an SG has determined that there is congestion in the indicate that an SG has determined that there is congestion in the
SS7 network to one or more destinations, or to an ASP in response to SS7 network to one or more destinations, or to an ASP in response to
a DATA or DAUD message as appropriate. For some MTP protocol a DATA or DAUD message as appropriate. For some MTP protocol
variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
congestion level changes. The SCON message MAY also be sent from the congestion level changes. The SCON message MAY also be sent from the
M3UA layer of an ASP to an M3UA peer indicating that the congestion M3UA layer of an ASP to an M3UA peer indicating that the congestion
level of the M3UA layer or the ASP has changed. level of the M3UA layer or the ASP has changed.
skipping to change at page 42, line 26 skipping to change at page 42, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length | | Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specifically useful for IPSP The optional ASP Identifier parameter is specifically useful for IPSP
communication. In that case the IPSP answering the ASP Up message MAY communication. In that case the IPSP answering the ASP Up message MAY
include its own ASP Identifier value. For AS-SG communication this include its own ASP Identifier value.
parameter MUST NOT be used.
The format and description of the optional INFO String parameter is The format and description of the optional INFO String parameter is
the same as for the DUNA message (See Section 3.4.1). The INFO the same as for the DUNA message (See Section 3.4.1). The INFO
String in an ASP Up Ack message is independent from the INFO String String in an ASP Up Ack message is independent from the INFO String
in the ASP Up message (i.e., it does not have to echo back the INFO in the ASP Up message (i.e., it does not have to echo back the INFO
String received). String received).
3.5.3 ASP Down 3.5.3 ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that The ASP Down message is used to indicate to a remote M3UA peer that
skipping to change at page 58, line 46 skipping to change at page 58, line 47
0x13 Unexpected Parameter 0x13 Unexpected Parameter
0x14 Destination Status Unknown 0x14 Destination Status Unknown
0x15 Invalid Network Appearance 0x15 Invalid Network Appearance
0x16 Missing Parameter 0x16 Missing Parameter
0x17 Not Used in M3UA 0x17 Not Used in M3UA
0x18 Not Used in M3UA 0x18 Not Used in M3UA
0x19 Invalid Routing Context 0x19 Invalid Routing Context
0x1a No Configured AS for ASP 0x1a No Configured AS for ASP
The "Invalid Version" error is sent if a message with an unsupported The "Invalid Version" error is sent if a message with an unsupported
version is received, the receiving end responds with an Error version is received, the receiving end responds with an Error message,
message, indicating the version the receiving node supports and indicating the version the receiving node supports and notifies layer
notifies layer management. management.
The "Unsupported Message Class" error is sent if a message with an The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. For this error, unexpected or unsupported Message Class is received. For this error,
the Diagnostic Information parameter MUST be included with the first the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message. 40 bytes of the offending message.
The "Unsupported Message Type" error is sent if a message with an The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. For this error, unexpected or unsupported Message Type is received. For this error,
the Diagnostic Information parameter MUST be included with the first the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message. 40 bytes of the offending message.
skipping to change at page 60, line 30 skipping to change at page 60, line 30
were not included in a message. This error is also sent if a were not included in a message. This error is also sent if a
conditional parameter is not included in the message but is required conditional parameter is not included in the message but is required
in the context of the received message. in the context of the received message.
The "Invalid Routing Context" error is sent if a message is received The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value. For from a peer with an invalid (unconfigured) Routing Context value. For
this error, the invalid Routing Context(s) MUST be included in the this error, the invalid Routing Context(s) MUST be included in the
Error message. Error message.
The "No Configured AS for ASP" error is sent if a message is received The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known from a peer without a Routing Context parameter and it is not known by
by configuration data which Application Servers are referenced. configuration data which Application Servers are referenced.
Diagnostic Information: variable length Diagnostic Information: variable length
When included, the optional Diagnostic information can be any When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in information germane to the error condition, to assist in
identification of the error condition. The Diagnostic information identification of the error condition. The Diagnostic information
SHOULD contain the offending message. The Diagnostic Information SHOULD contain the offending message. The Diagnostic Information
parameter with a zero length parameter is not considered as an parameter with a zero length parameter is not considered as an
error (this means that the Length field in the TLV will be set to error (this means that the Length field in the TLV will be set to
4). 4).
skipping to change at page 65, line 29 skipping to change at page 65, line 29
4.3 AS and ASP/IPSP State Maintenance 4.3 AS and ASP/IPSP State Maintenance
The M3UA layer on the SGP maintains the state of each remote ASP, in The M3UA layer on the SGP maintains the state of each remote ASP, in
each Application Server that the ASP is configured to receive each Application Server that the ASP is configured to receive
traffic, as input to the M3UA message distribution function. traffic, as input to the M3UA message distribution function.
Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
layer in an IPSP maintains the state of remote IPSPs. layer in an IPSP maintains the state of remote IPSPs.
Two IPSP models are defined as follows: Two IPSP models are defined as follows:
1- IPSP Single Exchange (SE) model. One IPSP takes the role of the 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM
client and the other the role of the server. The behavior then is and ASPSM messages are needed to change the IPSP states. This means
the same as the ASP-SGP scenario. An IPSP node following this that a set of request from one end and acknowledgement from the
model will be named as C-IPSP (client node) or S-IPSP (server other will be enough. The RK must define both sides of the traffic
node). The same node may act as a client with one peer IPSP and flow. Each exchange of ASPTM or ASPSM messages can be initiated by
server with another peer IPSP. Also upon common agreement the role either IPSP. For this exchange, the initiating IPSP follows the
(client/server) of the IPSPs can be changed in different dialogs procedures described in section 4.3.1.
between two IPSPs.
2- IPSP Double Exchange (DE) model. It turns to be a peer-to-peer 2- IPSP Double Exchange (DE) model. A double exchange of ASPTM and
communication from the very start-up, where both ends can start ASPSM messages are normally needed (ASPSM single exchange is
sending ASPTM and ASPSM messages. This may result in a double optional as a simplification). Each exchange of ASPTM or ASPSM
exchange of ASPTM and ASPSM message, one from each end. An IPSP messages can be initiated by either IPSP. The RKs define the
node following this model will be simply named as "D-IPSP". traffic to be directed to the peer as in the AS-SG model. Therefore
two different RKs are usually used, one installed on each peer.
In order to ensure interoperability, an M3UA implementation When using double exchanges for ASPSM messages, the management of
supporting IPSP communication MUST support IPSP SE model and MAY the connection in the two directions are considered independent.
implement IPSP DE model. This means that connections from IPSP-A to IPSP-B is handled in an
independent way that connection from IPSP-B to IPSP-A. Therefore it
could happen that only one of the two directions are activated or
closed, while the other remain in the same state as it was.
When using single exchange of ASPSM, what is seen as a
simplification, it is only the activation phase (ASPTM messages)
what is independent for each of the two directions. In this case it
could happen the sending the ASPSM from IPSP-A or IPSP-B will have
an effect in the whole communication as it is defined in the
standard SG-AS communication.
Because of these differences, there should be an agreements on the
way ASPSM messages are being handled before starting DE-IPSP
communication.
In order to ensure interoperability, an M3UA implementation supporting
IPSP communication MUST support IPSP SE model and MAY implement IPSP
DE model.
In section 4.3.1 ASP/IPSP States are described. In section 4.3.1 ASP/IPSP States are described.
In section 4.3.2, only the SGP-ASP scenario is described. All of the In section 4.3.2, only the SGP-ASP scenario is described. All of the
procedures referring to an AS served by ASPs are also applicable to procedures referring to an AS served by ASPs are also applicable to
ASes served by IPSPs. ASes served by IPSPs.
In section 4.3.3, only the Management procedures for the SGP-ASP In section 4.3.3, only the Management procedures for the SGP-ASP
scenario are described. The corresponding Management procedures for scenario are described. The corresponding Management procedures for
IPSPs are directly inferred. IPSPs are directly inferred.
The remaining sections contain specific IPSP Considerations sub- The remaining sections contain specific IPSP Considerations sub-
sections. sections.
4.3.1 ASP/IPSP States 4.3.1 ASP/IPSP States
The state of each remote ASP/IPSP, in each AS that it is configured The state of each remote ASP/IPSP, in each AS that it is configured to
to operate, is maintained in the peer M3UA layer (i.e. in the SGP or operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer
peer IPSP, respectively). The state of a particular ASP/IPSP in a IPSP, respectively). The state of a particular ASP/IPSP in a
particular AS changes due to events. The events include: particular AS changes due to events. The events include:
* Reception of messages from the peer M3UA layer at the ASP/IPSP; * Reception of messages from the peer M3UA layer at the ASP/IPSP;
* Reception of some messages from the peer M3UA layer at other * Reception of some messages from the peer M3UA layer at other
ASPs/IPSPs in the AS (e.g., ASP Active message indicating ASPs/IPSPs in the AS (e.g., ASP Active message indicating
"Override"); "Override");
* Reception of indications from the SCTP layer; or * Reception of indications from the SCTP layer; or
* Local Management intervention. * Local Management intervention.
The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3. The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3.
The possible states of an ASP/D-IPSP/C-IPSP are: The possible states of an ASP/D-IPSP/C-IPSP are:
ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable and/or ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable and/or
the related SCTP association is down. Initially all ASPs/IPSPs will the related SCTP association is down. Initially all ASPs/IPSPs will
be in this state. An ASP/IPSP in this state SHOULD NOT be sent any be in this state. An ASP/IPSP in this state SHOULD NOT be sent any
M3UA messages, with the exception of Heartbeat, ASP Down Ack and M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error
Error messages. messages.
ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and
the related SCTP association is up) but application traffic is the related SCTP association is up) but application traffic is
stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or stopped. In this state the ASP/IPSP SHOULD NOT be sent any DATA or
SSNM messages for the AS for which the ASP/IPSP is inactive. SSNM messages for the AS for which the ASP/IPSP is inactive.
ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and
application traffic is active (for a particular Routing Context or application traffic is active (for a particular Routing Context or
set of Routing Contexts). set of Routing Contexts).
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The
local SCTP layer will send this indication when it detects the loss local SCTP layer will send this indication when it detects the loss
of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood
as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
notification from the SCTP layer. notification from the SCTP layer.
SCTP RI: The local SCTP layer's Restart indication to the upper layer SCTP RI: The local SCTP layer's Restart indication to the upper layer
protocol (M3UA) on an SG. The local SCTP will send this indication protocol (M3UA) on an SG. The local SCTP will send this indication
when it detects a restart from the ASP's/IPSP's peer SCTP layer. when it detects a restart from the peer SCTP layer.
Figure 3: ASP State Transition Diagram, per AS Figure 3: ASP State Transition Diagram, per AS
+--------------+ +--------------+
| | | |
+----------------------| ASP-ACTIVE | +----------------------| ASP-ACTIVE |
| Other +-------| | | Other ASP/ +-------| |
| IPSP in AS | +--------------+ | IPSP in AS | +--------------+
| Overrides | ^ | | Overrides | ^ |
| | ASPAC/ | | ASPIA/ | | ASPAC/ | | ASPIA/
| |[ASPAC-Ack]| | [ASPIA-Ack] | |[ASPAC-Ack]| | [ASPIA-Ack]
| | | v | | | v
| | +--------------+ | | +--------------+
| | | | | | | |
| +------>| ASP-INACTIVE | | +------>| ASP-INACTIVE |
| | | | | |
| +--------------+ | +--------------+
skipping to change at page 67, line 30 skipping to change at page 67, line 50
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
SCTP RI | | | SCTP RI SCTP RI | | | SCTP RI
| | v | | v
| +--------------+ | +--------------+
| | | | | |
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
The transitions not in brackets are valid for: ASP, C-IPSP and D-IPSP The transitions are depicted as a result of the reception of ASP*M
state tracking. messages or other events. In some of the transitions there are some
messages in brackets. They mean that for a given node the state
transition will be different depending on its role: whether or not it
is generating the ASP*M request message (i.e. ASPUP, ASPAC, ASPIA or
ASPDN) or simply receiving it. In a peer-to-peer based architecture
(IPSP), this role may change between the peers.
The transitions in brackets are used for the IPSP DE model The transitions not in brackets are valid to track the states of ASPs
communication (D-IPSPs) and are related to the special cases when and IPSPs that send an ASP*M request message at the peer node.
The transition in brackets may be used in an ASP or in the IPSP that
receives an ASP*M request to track the peer SGP/IPSP states
respectively. There may be an SGP per AS state machine at ASPs.
Then the transitions in brackets can be used for the IPSP DE model
communication (DE-IPSPs) and are related to the special cases when
just one ASP*M messages exchange is needed, as follows: just one ASP*M messages exchange is needed, as follows:
- ASPSM messages. When sending ASPSM messages a single exchange could - ASPSM messages. When exchanging ASPSM messages using only a single
be sufficient. exchange (only one request and one acknowledgment). .
Example: whenever a D-IPSP is taking the leading role to start Example: (see section 5.6.2) whenever a DE-IPSP is taking the
communication to a peer D-IPSP, it sends ASP Up message to the peer leading role to start communication to a peer DE-IPSP, it sends ASP
D-IPSP. The peer is supposed to register the initiating D-IPSPS as Up message to the peer DE-IPSP. The peer MAY consider the initiating
being in ASP-INACTIVE state and answer back with ASP Up Ack. Upon DE-IPSPs as being in ASP-INACTIVE state, as it already sent a
the reception of this answer by the initiating D-IPSP it may think message, and answer back with ASP Up Ack. Upon the reception of this
of the peer as also being in ASP-UP state since it has responded. answer by the initiating DE-IPSP it alsoMAY consider the peer as
Therefore a second ASP Up message exchange to be started by the being in ASP-INACTIVE state since it did respond. Therefore a second
peer D-IPSP could be avoided. For this case the reception of ASP Up ASP Up message exchange to be started by the peer DE-IPSP could be
Ack may turn into a state change. avoided. In this case the reception of ASP Up Ack will turn into a
state change.
- ASPTM messages. When sending ASPTM messages to activate/deactivate - ASPTM messages. When sending ASPTM messages to activate/deactivate
all the traffic independently of routing keys, a single exchange all the traffic independently of routing keys by not specifying any
could be sufficient. RC, a single exchange could be sufficient.
Also the transition in brackets may be used in a C-IPSP/ASP to track
the peer S-IPSP/SGP states respectively.
4.3.2 AS States 4.3.2 AS States
The state of the AS is maintained in the M3UA layer on the SGPs. The The state of the AS is maintained in the M3UA layer on the SGPs. The
state of an AS changes due to events. These events include: state of an AS changes due to events. These events include:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
The possible states of an AS are: The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in ASP-DOWN state for this AS. Initially that all related ASPs are in ASP-DOWN state for this AS. Initially the
the AS will be in this state. An Application Server is in the AS-DOWN AS will be in this state. An Application Server is in the AS-DOWN
state when it is removed from a configuration. state when it is removed from a configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
traffic is active. One or more related ASPs are in ASP-INACTIVE state traffic is active. One or more related ASPs are in ASP-INACTIVE state
and/or the number of related ASPs in ASP-ACTIVE state has not reached and/or the number of related ASPs in ASP-ACTIVE state has not reached
n (n is the number of ASPs required to be in ASP-ACTIVE state before n (n is the number of ASPs required to be in ASP-ACTIVE state before
AS can transition to AS-ACTIVE, n = 1 for Override Traffic Mode) for AS can transition to AS-ACTIVE, n = 1 for Override Traffic Mode) for
this AS. The recovery timer T(r) is not running or has expired. this AS. The recovery timer T(r) is not running or has expired.
AS-ACTIVE: The Application Server is available and application AS-ACTIVE: The Application Server is available and application traffic
traffic is active. The AS moves to this state after being in AS- is active. The AS moves to this state after being in AS-INACTIVE and
INACTIVE and getting n ASPs (n is the number of ASPs required to be getting n ASPs (n is the number of ASPs required to be in ASP-ACTIVE
in ASP-ACTIVE state before AS can transition to AS-ACTIVE, n = 1 for state before AS can transition to AS-ACTIVE, n = 1 for Override
Override Traffic Mode) in ASP-ACTIVE state or, after reaching AS- Traffic Mode) in ASP-ACTIVE state or, after reaching AS-ACTIVE and
ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. keeping one or more ASPs in ASP-ACTIVE state.
When it is considered that one ASP is enough to handle traffic When it is considered that one ASP is enough to handle traffic (smooth
(smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the
as the first ASP moves to the ASP-ACTIVE state. first ASP moves to the ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP DOWN
DOWN and it was the last remaining active ASP in the AS. A recovery and it was the last remaining active ASP in the AS. A recovery timer
timer T(r) SHOULD be started and all incoming signalling messages T(r) SHOULD be started and all incoming signalling messages SHOULD be
SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires,
expires, the AS is moved to the AS-ACTIVE state and all the queued the AS is moved to the AS-ACTIVE state and all the queued messages
messages will be sent to the ASP. will be sent to the ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
alternative, the SGP may stops queuing messages and discards all alternative, the SGP may stop queuing messages and discards all
previously queued messages. The AS will move to the AS-INACTIVE previously queued messages. The AS will move to the AS-INACTIVE state
state. if at least one ASP is in ASP-INACTIVE, otherwise it will move to AS-
DOWN state.
Figure 4 shows an example AS state machine for the case where the Figure 4 shows an example AS state machine for the case where the
AS/ASP data is preconfigured and an n+k redundancy model. AS/ASP data is preconfigured and an n+k redundancy model. In other
cases where the AS/ASP configuration data is created dynamically,
there would be differences in the state machine, especially at
creation of the AS.
Figure 4: AS State Transition Diagram Figure 4: AS State Transition Diagram
+----------+ IA2AC +-------------+ +----------+ IA2AC +-------------+
| AS- |---------------------------->| AS- | | AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE | | INACTIVE | | ACTIVE |
| |<----------- | | | |<----------- | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ ^ | ^ | \ ^ |
| | IA2DN \ PN2IA | | AC2PN | | IA2DN \ PN2IA | | AC2PN
| | \ | | | | \ | |
DN2IA | | \ PN2AC | | DN2IA | | \ PN2AC | |
| v \ | v | v \ | v
skipping to change at page 69, line 23 skipping to change at page 70, line 8
| v \ | v | v \ | v
+----------+ \ +-------------+ +----------+ \ +-------------+
| | ----------| | | | ----------| |
| AS-DOWN | | AS-PENDING | | AS-DOWN | | AS-PENDING |
| | PN2DN | (queueing) | | | PN2DN | (queueing) |
| |<----------------------------| | | |<----------------------------| |
+----------+ +-------------+ +----------+ +-------------+
DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state.
IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that the
the all the ASPs are in ASP-DOWN state. all the ASPs are in ASP-DOWN state.
IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the ASP-
ASP-ACTIVE state to be n. ACTIVE state to be n.
In a special case of smooth start, this transition MAY be done when In a special case of smooth start, this transition MAY be done when
the first ASP moves to ASP-ACTIVE state. the first ASP moves to ASP-ACTIVE state.
AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-
DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1. DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1.
PN2AC: One ASP moves to ASP-ACTIVE. PN2AC: One ASP moves to ASP-ACTIVE.
PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE. PN2IA: T(r) Expiry, an ASP is in ASP-INACTIVE state but no ASPs are in
ASP-ACTIVE state.
PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state. PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state.
An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state
during the start-up phase (except for smooth start). Once the traffic during the start-up phase (except for smooth start). Once the traffic
is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns to
to another state different to ASP-ACTIVE, avoiding unnecessary another state different to ASP-ACTIVE, avoiding unnecessary traffic
traffic disturbances as long as there are ASPs available, in the disturbances as long as there are ASPs available, in the assumption
assumption that the system will not always be exposed to the maximum that the system will not always be exposed to the maximum load.
load.
There are other cases where the AS/ASP configuration data is created There are other cases where the AS/ASP configuration data is created
dynamically. In those cases there would be differences in the state dynamically. In those cases there would be differences in the state
machine, especially at creation of the AS. For example, where the machine, especially at creation of the AS. For example, where the
AS/ASP configuration data is not created until Registration of the AS/ASP configuration data is not created until Registration of the
first ASP, the AS-INACTIVE state is entered directly upon the nth first ASP, the AS-INACTIVE state is entered directly upon the nth
successful REG REQ from an ASP belonging to that AS. Another example successful REG REQ from an ASP belonging to that AS. Another example
is where the AS/ASP configuration data is not created until the nth is where the AS/ASP configuration data is not created until the nth
ASP successfully enters the ASP-ACTIVE state. In this latter case ASP successfully enters the ASP-ACTIVE state. In this latter case the
the AS-ACTIVE state is entered directly. AS-ACTIVE state is entered directly.
4.3.3 M3UA Management Procedures for Primitives 4.3.3 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association the ASP state at both Before the establishment of an SCTP association the ASP state at both
the SGP and ASP is assumed to be in the state ASP-DOWN. the SGP and ASP is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (see Section 4.2) and Once the SCTP association is established (see Section 4.2) and
assuming that the local M3UA-User is ready, the local M3UA ASP assuming that the local M3UA-User is ready, the local M3UA ASP
Maintenance (ASPM) function will initiate the relevant procedures, Maintenance (ASPM) function will initiate the relevant procedures,
using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
skipping to change at page 71, line 49 skipping to change at page 72, line 32
If an ASP Up message is received and internally the remote ASP is in If an ASP Up message is received and internally the remote ASP is in
the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as, the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as,
an Error message ("Unexpected Message). In addition, the remote ASP an Error message ("Unexpected Message). In addition, the remote ASP
state is changed to ASP-INACTIVE in all relevant Application Servers state is changed to ASP-INACTIVE in all relevant Application Servers
and all registered Routing Keys are considered deregistered. and all registered Routing Keys are considered deregistered.
If an ASP Up message is received and internally the remote ASP is If an ASP Up message is received and internally the remote ASP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken. and no further action is taken.
If the ASP receives an unexpected ASP Up Ack message, the ASP should
consider itself in the ASP-INACTIVE state. If the ASP was not in the
ASP-INACTIVE state, it SHOULD send an Error message and then initiate
procedures to return itself to its previous state.
4.3.4.1.1 M3UA Version Control and ASP Up 4.3.4.1.1 M3UA Version Control and ASP Up
If an ASP Up message with an unsupported version is received, the If an ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management. See the receiving node supports and notifies Layer Management. See section
section 4.8 for more on this issue. 4.8 for more on this issue.
4.3.4.1.2 IPSP Considerations (ASP Up) 4.3.4.1.2 IPSP Considerations (ASP Up)
An IPSP may be considered in the ASP-INACTIVE state after an ASP Up An IPSP may be considered in the ASP-INACTIVE state after an ASP Up
or ASP Up Ack has been received from it. An IPSP can be considered or ASP Up Ack has been received from it. An IPSP can be considered
in the ASP-DOWN state after an ASP Down or ASP Down Ack has been in the ASP-DOWN state after an ASP Down or ASP Down Ack has been
received from it. The IPSP may inform Layer Management of the change received from it. The IPSP may inform Layer Management of the change
in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or
confirmation primitives. confirmation primitives.
Alternatively, when using IPSP DE model, an interchange of ASP Up Alternatively, when using IPSP DE model, an interchange of ASP Up
messages from each end MUST be performed. Four messages are needed messages from each end MUST be performed. Four messages are needed for
for completion. completion.
If for any local reason (e.g., management lockout) an IPSP cannot 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 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 to an ASP Up message with an Error message with reason "Refused
Management Blocking" and leaves the remote IPSP in the ASP-DOWN Management Blocking" and leaves the remote IPSP in the ASP-DOWN
state. state.
4.3.4.2 ASP-Down Procedures 4.3.4.2 ASP-Down Procedures
The ASP will send an ASP Down message to an SGP when the ASP wishes The ASP will send an ASP Down message to an SGP when the ASP wishes
skipping to change at page 74, line 18 skipping to change at page 75, line 6
or IPSP to independently acknowledge the ASP Active message for or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. different (sets of) Routing Contexts.
The ASP Active message will be responded in the following way as a The ASP Active message will be responded in the following way as a
function of the presence/need of the RC parameter: function of the presence/need of the RC parameter:
- If the RC parameter is included in the ASP Active message and the - If the RC parameter is included in the ASP Active message and the
corresponding RK has been previously defined (by either static corresponding RK has been previously defined (by either static
configuration or dynamic registration), the peer node MUST respond configuration or dynamic registration), the peer node MUST respond
with an ASP Active Ack message. If for any local reason (e.g. with an ASP Active Ack message. If for any local reason (e.g.
management lockout) the SGP responds t an ASP Active message with management lockout) the SGP responds t an ASP Active message with an
an Error message with reason ôRefused ű Management Blockingö. Error message with reason "Refused ű Management Blocking".
- If the RC parameter is included in the ASP Active message and a - If the RC parameter is included in the ASP Active message and a
corresponding RK has not been previously defined (by either static corresponding RK has not been previously defined (by either static
configuration or dynamic registration), the peer MUST respond with configuration or dynamic registration), the peer MUST respond with
an ERROR message with Error Code = "No configured AS for ASP". an ERROR message with Error Code = "No configured AS for ASP".
- If the RC parameter is not included in the ASP Active message, - If the RC parameter is not included in the ASP Active message, there
there are RKs defined (by either static configuration or dynamic are RKs defined (by either static configuration or dynamic
registration) and RC is not mandatory, the peer node SHOULD respond registration) and RC is not mandatory, the peer node SHOULD respond
with an ASP Active Ack message and activate all the RKs it has with an ASP Active Ack message and activate all the RKs it has
defined for that specific ASP. defined for that specific ASP.
- If the RC parameter is not included in the ASP Active message, - If the RC parameter is not included in the ASP Active message, there
there are RKs defined (by either static configuration or dynamic are RKs defined (by either static configuration or dynamic
registration) and RC is mandatory, the peer node MUST respond with registration) and RC is mandatory, the peer node MUST respond with
and ERROR message with the Error Code = "Missing Parameter". and ERROR message with the Error Code = "Missing Parameter".
- If the RC parameter is not included in the ASP Active message, - If the RC parameter is not included in the ASP Active message, there
there are RKs defined (by either static configuration or dynamic are RKs defined (by either static configuration or dynamic
registration) and RC is not mandatory, the peer node MUST respond registration) and RC is not mandatory, the peer node MUST respond
with an ASP Active Ack message if it is ready to handle traffic; with an ASP Active Ack message if it is ready to handle traffic;
otherwise it will send an ERROR message with the Error Code = "No otherwise it will send an ERROR message with the Error Code = "No
Configured AS for ASP" (meaning that it is not ready to become Configured AS for ASP" (meaning that it is not ready to become
active). active).
- If the RC parameter is not included in the ASP Active message and - If the RC parameter is not included in the ASP Active message and
there are no RKs defined, the peer node SHOULD respond with and there are no RKs defined, the peer node SHOULD respond with and
ERROR message with the Error Code = "Invalid Routing Context". ERROR message with the Error Code = "Invalid Routing Context".
Independently of the RC, the SGP MUST send an ASP Active message in Independently of the RC, the SGP MUST send an ASP Active Ack message
response to a received ASP Active message from the ASP, if the ASP in response to a received ASP Active message from the ASP, if the ASP
is already marked in the APS-ACTIVE state. is already marked in the APS-ACTIVE state.
At the ASP, the ASP Active Ack message received is not acknowledged. At the ASP, the ASP Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_ACTIVE confirm primitive. Layer Management is informed with an M-ASP_ACTIVE confirm primitive.
It is possible for the ASP to receive Data message(s) before the ASP It is possible for the ASP to receive Data message(s) before the ASP
Active Ack message as the ASP Active Ack and Data messages from an SG Active Ack message as the ASP Active Ack and Data messages from an SG
or IPSP may be sent on different SCTP streams. Message loss is or IPSP may be sent on different SCTP streams. Message loss is
possible as the ASP does not consider itself in the ASP-ACTIVE state possible as the ASP does not consider itself in the ASP-ACTIVE state
until reception of the ASP Active Ack message. until reception of the ASP Active Ack message.
When the ASP sends an ASP Active message it starts timer T(ack). If When the ASP sends an ASP Active message it starts timer T(ack). If
the ASP does not receive a response to an ASP Active message within the ASP does not receive a response to an ASP Active message within
T(ack), the ASP MAY restart T(ack) and resend ASP Active messages T(ack), the ASP MAY restart T(ack) and resend ASP Active messages
until it receives an ASP Active Ack message. T(ack) is until it receives an ASP Active Ack message. T(ack) is
skipping to change at page 77, line 6 skipping to change at page 77, line 44
4.3.4.3.1 IPSP Considerations (ASP Active) 4.3.4.3.1 IPSP Considerations (ASP Active)
Either of the IPSPs can initiate communication. When an IPSP receives Either of the IPSPs can initiate communication. When an IPSP receives
an ASP Active, it should mark the peer as ASP-ACTIVE and return an 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 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- may mark the peer as ASP-Active, if it is not already in the ASP-
ACTIVE state. ACTIVE state.
Alternatively, when using IPSP DE model, an interchange of ASP Active Alternatively, when using IPSP DE model, an interchange of ASP Active
messages from each end MUST be performed. Four messages are needed messages from each end MUST be performed. Four messages are needed for
for completion. completion.
4.3.4.4 ASP Inactive Procedures 4.3.4.4 ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS, When an ASP wishes to withdraw from receiving traffic within an AS, or
or the ASP wants to initiate the process of deactivation, the ASP the ASP wants to initiate the process of deactivation, the ASP sends
sends an ASP Inactive message to the SGP or IPSP. an ASP Inactive message to the SGP or IPSP.
An ASP Inactive message MUST always be responded by the peer An ASP Inactive message MUST always be responded by the peer (although
(although other messages may be sent in the middle) in the following other messages may be sent in the middle) in the following way:
way:
- If the ASP Inactive message contains a RC parameter and the - If the received ASP Inactive message contains a RC parameter and
corresponding RK is defined (by either static configuration or the corresponding RK is defined (by either static configuration
dynamic registration), the peer MUST respond with an ASP or dynamic registration), the SGP/IPSP MUST respond with an ASP
Inactive Ack message. Inactive Ack message.
- If the ASP Inactive message contains a RC parameter that is not - If the received ASP Inactive message contains a RC parameter
defined (by either static configuration or dynamic that is not defined (by either static configuration or dynamic
registration), the peer MUST respond with an ERROR message with registration), the SGP/IPSP MUST respond with an ERROR message
Error Code = "Invalid Routing Context". with Error Code = "Invalid Routing Context".
- If the ASP Inactive message does not contain a RC parameter and - If the received ASP Inactive message does not contain a RC
the RK is defined (by either static configuration or dynamic parameter and the RK is defined (by either static configuration
registration), the peer must turn the ASP/IPSP to ASP-INACTIVE or dynamic registration), the SGP/IPSP must turn the ASP/IPSP to
state in all the ASes it serves and MUST respond with an ASP ASP-INACTIVE state in all the ASes it serves and MUST respond
Inactive Ack message. with an ASP Inactive Ack message.
- If the ASP Inactive message does not contain a RC parameter and - If the received ASP Inactive message does not contain a RC
the RK is not defined (by either static configuration or dynamic parameter and the RK is not defined (by either static
registration), the peer MUST respond with an ERROR message with configuration or dynamic registration), the SGP/IPSP MUST
Error Code = "No configured AS for ASP". respond with an ERROR message with Error Code = "No configured
AS for ASP".
The action of sending the ASP Inactive message MAY be initiated at The action of sending the ASP Inactive message MAY be initiated at the
the ASP by an M-ASP_INACTIVE request primitive from Layer Management ASP by an M-ASP_INACTIVE request primitive from Layer Management or
or MAY be initiated automatically by an M3UA management function. In MAY be initiated automatically by an M3UA management function. In the
the case where an ASP is processing the traffic for more than one case where an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive Application Server across a common SCTP association, the ASP Inactive
message contains one or more Routing Contexts to indicate for which message contains one or more Routing Contexts to indicate for which
Application Servers the ASP Inactive message applies. Application Servers the ASP Inactive message applies.
In the case where an ASP Inactive message does not contain a Routing In the case where an ASP Inactive message does not contain a Routing
Context parameter, the receiver must know, via configuration data, Context parameter, the receiver must know, via configuration data,
which Application Servers the ASP is a member and move the ASP to the which Application Servers the ASP is a member and move the ASP to the
ASP-INACTIVE state in all Application Servers. ASP-INACTIVE state in all Application Servers.
In the case of an Override mode AS, where another ASP has already In the case of an Override mode AS, where another ASP has already
skipping to change at page 81, line 27 skipping to change at page 82, line 17
"Unsupported Message Class". "Unsupported Message Class".
If the SGP determines that the received Routing Key data is invalid, If the SGP determines that the received Routing Key data is invalid,
or contains invalid parameter values, the SGP returns a Registration or contains invalid parameter values, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error Response message to the ASP, containing a Registration Result "Error
Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network
Appearance" as appropriate. Appearance" as appropriate.
If the SGP determines that the requested RK partially, but not If the SGP determines that the requested RK partially, but not
exactly, matches an existing RK, and that an incoming signalling exactly, matches an existing RK, and that an incoming signalling
message received at an SGP could possibly match both the requested message received at an SGP could possibly match both the requested and
and the existing RK, the SGP returns a Registration Response message the existing RK, the SGP returns a Registration Response message to
to the ASP, with a Registration Status of "Error - "Cannot Support the ASP, with a Registration Status of "Error - "Cannot Support Unique
Unique Routing. An incoming signalling message received at an SGP Routing. An incoming signalling message received at an SGP should not
should not match against more than one Routing Key. match against more than one Routing Key.
If the SGP determines that the received RK was already registered, If the SGP determines that the received RK was already registered,
fully and exactly, either statically or dynamically, by the sending fully and exactly, either statically or dynamically, by the sending
ASP, the SGP returns a Registration Response message to the ASP, ASP, the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Routing Key Already containing a Registration Result "Error - Routing Key Already
Registered ". This error applies whether the sending ASP/IPSP is in Registered ". This error applies whether the sending ASP/IPSP is in
ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error
code, the RC field in the Registration Response message MUST be code, the RC field in the Registration Response message MUST be
populated with the actual value of RC in SGP corresponding to the populated with the actual value of RC in SGP corresponding to the
specified RK in the Registration Request message. specified RK in the Registration Request message.
An ASP MAY request modification of an existing Routing Key by An ASP MAY request modification of an existing Routing Key by
including a Routing Context parameter in a Registration Request including a Routing Context parameter in a Registration Request
message. Upon receipt of a Registration Request message containing a message. Upon receipt of a Registration Request message containing a
Routing Context, if the SGP determines that the Routing Context Routing Context, if the SGP determines that the Routing Context
applies to an existing Routing Key, the SGP MAY adjust the existing applies to an existing Routing Key, the SGP MAY adjust the existing
Routing Key to match the new information provided in the Routing Key Routing Key to match the new information provided in the Routing Key
parameter. A Registration Response "ERR ű Routing Key Change Refused" parameter. A Registration Response "ERR ű Routing Key Change Refused"
is returned if the SGP does not support this re-registration is returned if the SGP does not support this re-registration procedure
procedure or RC does not exist. Otherwise, a Registration Response or RC does not exist. Otherwise, a Registration Response "Successfully
"Successfully Registered" is returned. Registered" is returned.
If the SGP does not authorize an otherwise valid registration If the SGP does not authorize an otherwise valid registration request,
request, the SGP returns a REG RSP message to the ASP containing the the SGP returns a REG RSP message to the ASP containing the
Registration Result "Error - Permission Denied". Registration Result "Error - Permission Denied".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SGP does not support dynamic configuration, the SGP exist and the SGP does not support dynamic configuration, the SGP
returns a Registration Response message to the ASP, containing a returns a Registration Response message to the ASP, containing a
Registration Result "Error - Routing Key not Currently Provisioned". Registration Result "Error - Routing Key not Currently Provisioned".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SGP supports dynamic configuration but does not have exist and the SGP supports dynamic configuration but does not have
the capacity to add new Routing Key and Application Server entries, the capacity to add new Routing Key and Application Server entries,
the SGP returns a Registration Response message to the ASP, the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Insufficient Resources". containing a Registration Result "Error - Insufficient Resources".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist, and the SGP supports dynamic configuration but requires that exist, and the SGP supports dynamic configuration but requires that
the Routing Key first be manually provisioned at the SGP, the SGP the Routing Key first be manually provisioned at the SGP, the SGP
returns a Registration Response message to the ASP, containing a returns a Registration Response message to the ASP, containing a
Registration Result "Error - Routing Key not Currently Provisioned. Registration Result "Error - Routing Key not Currently Provisioned.
If an SGP determines that one or more of the Routing Key parameters If an SGP determines that one or more of the Routing Key parameters
are not supported for the purpose of creating new Routing Key are not supported for the purpose of creating new Routing Key entries,
entries, the SGP returns a Registration Response message to the ASP, the SGP returns a Registration Response message to the ASP, containing
containing a Registration Result "Error - Unsupported RK parameter a Registration Result "Error - Unsupported RK parameter field.
field.
A Registration Response "Error - Unsupported Traffic Handling Mode" A Registration Response "Error - Unsupported Traffic Handling Mode"
is returned if the Routing Key in the REG REQ contains an Traffic is returned if the Routing Key in the REG REQ contains an Traffic
Handling Mode that is inconsistent with the presently configured mode Handling Mode that is inconsistent with the presently configured mode
for the matching Application Server. for the matching Application Server.
An ASP MAY register multiple Routing Keys at once by including a An ASP MAY register multiple Routing Keys at once by including a
number of Routing Key parameters in a single REG REQ message. The number of Routing Key parameters in a single REG REQ message. The
SGP MAY respond to each registration request in a single REG RSP SGP MAY respond to each registration request in a single REG RSP
message, indicating the success or failure result for each Routing message, indicating the success or failure result for each Routing
skipping to change at page 83, line 37 skipping to change at page 84, line 25
An ASP MAY deregister multiple Routing Contexts at once by including An ASP MAY deregister multiple Routing Contexts at once by including
a number of Routing Contexts in a single DEREG REQ message. The SGP a number of Routing Contexts in a single DEREG REQ message. The SGP
MAY respond to each deregistration request in a single DEREG RSP MAY respond to each deregistration request in a single DEREG RSP
message, indicating the success or failure result for each Routing message, indicating the success or failure result for each Routing
Context in a separate Deregistration Result parameter. Context in a separate Deregistration Result parameter.
4.4.3 IPSP Considerations (REG/DEREG) 4.4.3 IPSP Considerations (REG/DEREG)
The Registration/Deregistration procedures work in the IPSP cases in The Registration/Deregistration procedures work in the IPSP cases in
the same way as in AS-SG cases. An IPSP may register an RK in the the same way as in AS-SG cases. An IPSP may register an RK in the
remote IPSP. An IPSP is responsible for deregistering the RKs that remote IPSP. An IPSP is responsible for deregistering the RKs that it
it has registered. has registered.
4.5 Procedures to Support the Availability or Congestion Status of SS7 4.5 Procedures to Support the Availability or Congestion Status of SS7
Destination Destination
4.5.1 At an SGP 4.5.1 At an SGP
On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
primitive from the nodal interworking function at an SGP, the SGP primitive from the nodal interworking function at an SGP, the SGP
M3UA layer will send a corresponding SS7 Signalling Network M3UA layer will send a corresponding SS7 Signalling Network
Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4)
to the M3UA peers at concerned ASPs. The M3UA layer must fill in to the M3UA peers at concerned ASPs. The M3UA layer must fill in
various fields of the SSNM messages consistently with the information various fields of the SSNM messages consistently with the information
received in the primitives. received in the primitives.
The SGP M3UA layer determines the set of concerned ASPs to be The SGP M3UA layer determines the set of concerned ASPs to be informed
informed based on the specific SS7 network for which the primitive based on the specific SS7 network for which the primitive indication
indication is relevant. In this way, all ASPs configured to is relevant. In this way, all ASPs configured to send/receive traffic
send/receive traffic within a particular network appearance are within a particular network appearance are informed. If the SGP
informed. If the SGP operates within a single SS7 network operates within a single SS7 network appearance, then all ASPs are
appearance, then all ASPs are informed. informed.
For the particular case that an ASP becomes active for an AS and For the particular case that an ASP becomes active for an AS and
destinations normally accessible to the AS are inaccessible, destinations normally accessible to the AS are inaccessible,
restricted or congested, the SG MAY send DUNA, DRST or SCON messages restricted or congested, the SG MAY send DUNA, DRST or SCON messages
for the inaccessible, restricted or congested destinations to the ASP for the inaccessible, restricted or congested destinations to the ASP
newly active for the AS to prevent the ASP from sending traffic for newly active for the AS to prevent the ASP from sending traffic for
destinations that it might otherwise not know that are inaccessible, destinations that it might otherwise not know that are inaccessible,
restricted or congested. For the newly activating ASP from which the restricted or congested. For the newly activating ASP from which the
SGP has received an ASP Active message, these DUNA, DRST and SCON SGP has received an ASP Active message, these DUNA, DRST and SCON
messages MAY be sent before sending the ASP Active Ack that completes messages MAY be sent before sending the ASP Active Ack that completes
skipping to change at page 85, line 38 skipping to change at page 86, line 23
issuing a DAUD. In this case the DAUD is sent to the issuing a DAUD. In this case the DAUD is sent to the
SGP that originally sent the SSNM message. SGP that originally sent the SSNM message.
- Isolation. The ASP is newly ASP-ACTIVE or has been - Isolation. The ASP is newly ASP-ACTIVE or has been
isolated from an SGP for an extended period. The ASP isolated from an SGP for an extended period. The ASP
MAY request the availability/congestion status of one MAY request the availability/congestion status of one
or more SS7 destinations to which it expects to or more SS7 destinations to which it expects to
communicate. communicate.
IMPLEMENTATION NOTE: In the first of the cases above, the auditing IMPLEMENTATION NOTE: In the first of the cases above, the auditing
procedure must not be invoked for the case of a received SCON message procedure must not be invoked for the case of a received SCON
message
containing a congestion level value of "no congestion" or undefined" containing a congestion level value of "no congestion" or undefined"
(i.e., congestion Level = "0"). (i.e., congestion Level = "0").
The SGP SHOULD respond to a DAUD message with the MTP3 The SGP SHOULD respond to a DAUD message with the MTP3
availability/congestion status of the routeset associated with each availability/congestion status of the routeset associated with each
Destination Point Code(s) in the DAUD message. The status of each SS7 Destination Point Code(s) in the DAUD message. The status of each SS7
destination requested is indicated in a DUNA message (if destination requested is indicated in a DUNA message (if unavailable),
unavailable), a DAVA message (if available ), or a DRST (if a DAVA message (if available ), or a DRST (if restricted and the SGP
restricted and the SGP supports this feature (national networks), the supports this feature in national networks). For national networks,
SGP MUST additionally respond with a SCON message before the DAVA or the SGP SHOULD additionally respond with a SCON message (if the
DRST. For unknown SS7 destinations, the SGP MAY respond with a DUNA destination is congested) before the DAVA or DRST.
message, as it has no routing information to allow it to route
traffic to this destination.
Where the SGP does not maintain the congestion status of the SS7 Where the SGP does not maintain the congestion status of the SS7
destination, the response to a DAUD message should always be only a destination, the response to a DAUD message should always be only a
DAVA, DRST or DUNA message as appropriate. DAVA, DRST or DUNA message as appropriate.
Any DUNA or DAVA message in response to a DAUD message MAY contain a Any DUNA or DAVA message in response to a DAUD message MAY contain a
list of Affected Point Codes. list of Affected Point Codes.
An SG MAY refuse to provide the availability or congestion status of An SG MAY refuse to provide the availability or congestion status of
a destination if, for example, the ASP is not authorized to know the a destination if, for example, the ASP is not authorized to know the
status of the destination. The SG MAY respond with an Error Message status of the destination. The SG MAY respond with an Error Message
(Error Code = "Destination Status Unknown") (Error Code = "Destination Status Unknown").
An SG SHOULD response with a DUNA message when DAUD was received with
an unknown Signalling Point Code.
4.6 MTP3 Restart 4.6 MTP3 Restart
In the case where the MTP3 in the SG undergoes an MTP restart, event In the case where the MTP3 in the SG undergoes an MTP restart, event
communication SHOULD be handled as follows: communication SHOULD be handled as follows:
When the SG discovers SS7 network isolation, the SGPs send an When the SG discovers SS7 network isolation, the SGPs send an
indication to all concerned available ASPs (i.e., ASPs in the ASP- indication to all concerned available ASPs (i.e., ASPs in the ASP-
ACTIVE state) using DUNA messages for the concerned destinations. ACTIVE state) using DUNA messages for the concerned destinations.
skipping to change at page 86, line 47 skipping to change at page 87, line 34
destinations by sending DAUD messages. This would be for example the destinations by sending DAUD messages. This would be for example the
case when an AS becomes active at an ASP and does not have current case when an AS becomes active at an ASP and does not have current
destination statuses. If MTP restart is in progress at the SG, the destination statuses. If MTP restart is in progress at the SG, the
SGP returns a DUNA message for that destination, even if it received SGP returns a DUNA message for that destination, even if it received
an indication that the destination became available or restricted. an indication that the destination became available or restricted.
When an ASP becomes active for an AS and the SG is experiencing SS7 When an ASP becomes active for an AS and the SG is experiencing SS7
network isolation or is performing the MTP Restart procedure for the network isolation or is performing the MTP Restart procedure for the
AS, the SG MAY send a DUNA message for the concerned destinations to AS, the SG MAY send a DUNA message for the concerned destinations to
the newly active ASP to prevent the ASP from sending traffic. These the newly active ASP to prevent the ASP from sending traffic. These
messages can be sent after receiving the ASP Active and before messages can be sent after receiving the ASP Active and before sending
sending the ASP Active Ack in order to ensure that traffic is not the ASP Active Ack to ensure that traffic is not initiated by the ASP
initiated by the ASP to these destinations before the SSNM are to these destinations before the SSNM are received. In addition to
received. In addition to DUNA messages, DRST and DAVA can also be DUNA messages, SCON, DRST and DAVA can also be sent.
sent.
In the IPSP case, MTP restart could be considered if the IPSP also In the IPSP case, MTP restart could be considered if the IPSP also
has connection to an SS7 network. In that case, the same behavior as has connection to an SS7 network. In that case, the same behavior as
described above for the SGP would apply to the restarting IPSP. This described above for the SGP would apply to the restarting IPSP. This
would also be the case if the IPSPs were perceived as exchanging MTP would also be the case if the IPSPs were perceived as exchanging MTP
Peer PDUs, instead of MTP primitives between MTP User and MTP Peer PDUs, instead of MTP primitives between MTP User and MTP
Provider. In other words, M3UA does not provide the equivalent to Provider. In other words, M3UA does not provide the equivalent to
Traffic Restart Allowed messages indicating the end of the restart Traffic Restart Allowed messages indicating the end of the restart
procedure between peer IPSPs that would also be connected to an SS7 procedure between peer IPSPs that would also be connected to an SS7
network. network.
4.7 NIF not Available 4.7 NIF not Available
IMPLEMENTATION NOTE: Although the NIF is decided to be an IMPLEMENTATION NOTE: Although the NIF is decided to be an
implementation dependent function, here there are some guidelines implementation dependent function, here there are some guidelines that
that may be useful to follow: may be useful to follow:
- If an SGP is isolated entirely from the NIF, the SGP should send - If an SGP is isolated entirely from the NIF, the SGP should send ASP
ASP Down Ack to all its connected ASPs. Upon receiving an ASP Up Down Ack to all its connected ASPs. Upon receiving an ASP Up
message while isolated from the NIF, the SGP should respond with message while isolated from the NIF, the SGP should respond with
Error("Refused - Management Blocking"). Error("Refused - Management Blocking").
- If an SGP suffers a partial failure (where an SGP can continue to - If an SGP suffers a partial failure (where an SGP can continue to
service one or more active AS, but due to a partial failure it is service one or more active AS, but due to a partial failure it is
unable to service one or more other active AS), the SGP should send unable to service one or more other active AS), the SGP should send
ASP Inactive Ack to all its connected ASPs for the affected AS. ASP Inactive Ack to all its connected ASPs for the affected AS. Upon
Upon receiving an ASP Active message for an affected AS and while receiving an ASP Active message for an affected AS and while still
still partially isolated from the NIF, the SGP should respond with partially isolated from the NIF, the SGP should respond with
Error("Refused - Management Blocking"). Error("Refused - Management Blocking").
- If SG is isolated from NIF it means that each SGP within an SG - If SG is isolated from NIF it means that each SGP within an SG
should follow the procedure mentioned above. should follow the procedure mentioned above.
4.8 M3UA Version Control 4.8 M3UA Version Control
If a message with an unsupported version is received, the receiving If a message with an unsupported version is received, the receiving
end responds with an Error message, indicating the version the end responds with an Error message, indicating the version the
receiving node supports and notifies Layer Management. receiving node supports and notifies Layer Management.
This is useful when protocol version upgrades are being performed in This is useful when protocol version upgrades are being performed in a
a network. A node upgraded to a newer version should support the network. A node upgraded to a newer version should support the older
older versions used on other nodes it is communicating with. Because versions used on other nodes it is communicating with. Because ASPs
ASPs initiate the ASP Up procedure it is likely that the message initiate the ASP Up procedure it is likely that the message
having an unsupported version is an ASP Up message and therefore that having an unsupported version is an ASP Up message and therefore that
the Error message would normally come from the SGP. the Error message would normally come from the SGP.
4.9 M3UA Termination
Whenever a M3UA node wants to stop the communication with the peer
node, it MAY use one of the following procedures
a) Send the sequence of ASP-INACTIVE, DEREG (optionally whenever
dynamic registration is used), ASP-DOWN messages and perform the
SCTP Shutdown procedure after that.
b) Just do the SCTP Shutdown procedure.
5. Examples of M3UA Procedures 5. Examples of M3UA Procedures
5.1 Establishment of Association and Traffic between SGPs and ASPs 5.1 Establishment of Association and Traffic between SGPs and ASPs
These scenarios show the example M3UA message flows for the These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two establishment of traffic between an SGP and an ASP or between two
IPSPs. In all cases it is assumed that the SCTP association is IPSPs. In all cases it is assumed that the SCTP association is
already set up. already set up.
5.1.1 Single ASP in an Application Server ("1+0" sparing), 5.1.1 Single ASP in an Application Server ("1+0" sparing),
skipping to change at page 89, line 41 skipping to change at page 90, line 41
|-----ASP Active Ack (RC1)----->| |-----ASP Active Ack (RC1)----->|
| | | |
|----NOTIFY(AS-ACTIVE)(RC1)---->| |----NOTIFY(AS-ACTIVE)(RC1)---->|
| | | |
~ ~ ~ ~
| | | |
|<----REGISTER REQ(LRCn,RKn)----| |<----REGISTER REQ(LRCn,RKn)----|
| | | |
|----REGISTER RESP(LRCn,RCn)--->| |----REGISTER RESP(LRCn,RCn)--->|
| | | |
|----NOTIFY(AS-ACTIVE)(RCn)---->| |---NOTIFY(AS-INACTIVE)(RCn)--->|
| | | |
|<------- ASP Active(RCn)-------| |<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->| |-----ASP Active Ack (RCn)----->|
| | | |
|----NOTIFY(AS-ACTIVE)(RCn)---->| |----NOTIFY(AS-ACTIVE)(RCn)---->|
| | | |
Note: In the case of an unsuccessful registration attempt (e.g., Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP will not subsequently send an ASP unsuccessful indication and the ASP will not subsequently send an ASP
skipping to change at page 104, line 42 skipping to change at page 105, line 42
[15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); [15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2; Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification" Part 1: Protocol specification"
[16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd [16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
Generation partnership Project; Technical Specification Group Generation partnership Project; Technical Specification Group
Radio Access Network; UTRAN Iu Interface: General Aspects and Radio Access Network; UTRAN Iu Interface: General Aspects and
Principles" Principles"
[17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T., [17] Stewart, R., Xie, Q., Morneault, K., Sharp, H., Taylor, T.,
Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control
Transport Protocol", RFC 2960, October 2000. Transport Protocol", RFC 2960, October 2000.
[18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - [18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer -
Service Specific Coordination Function for signalling at the Service Specific Coordination Function for signalling at the
Network Node Interface (SSCF at NNI)" Network Node Interface (SSCF at NNI)"
[19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - [19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer -
Service Specific Connection Oriented Protocol (SSCOP)" Service Specific Connection Oriented Protocol (SSCOP)"
skipping to change at page 106, line 8 skipping to change at page 107, line 8
Ian Rytina - Ericsson Ian Rytina - Ericsson
Guy Mousseau - Nortel Networks Guy Mousseau - Nortel Networks
Lyndon Ong - Ciena Lyndon Ong - Ciena
Hanns Juergen Schwarzbauer - Siemens Hanns Juergen Schwarzbauer - Siemens
Klaus Gradischnig - Detecon Inc. Klaus Gradischnig - Detecon Inc.
Mallesh Kalla - Telcordia Mallesh Kalla - Telcordia
Normand Glaude - Performance Technologies Normand Glaude - Performance Technologies
Brian Bidulock - OpenSS7 Brian Bidulock - OpenSS7
John Loughney ű Nokia John Loughney - Nokia
Greg Sidebottom ű Signatus Technologies Greg Sidebottom - Signatus Technologies
Appendix A Appendix A
A.1 Signalling Network Architecture A.1 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction requirements for such transport by itself. However, the conjunction
skipping to change at page 106, line 40 skipping to change at page 108, line 34
This can typically be achieved through the use of redundant SGPs or This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points. network paths for SCTP Associations between SCTP End Points.
Obviously, the reliability of the SG, the MGC and other IP-based Obviously, the reliability of the SG, the MGC and other IP-based
functional elements also needs to be taken into account. The functional elements also needs to be taken into account. The
distribution of ASPs and SGPs within the available Hosts MAY also be distribution of ASPs and SGPs within the available Hosts MAY also be
considered. As an example, for a particular Application Server, the considered. As an example, for a particular Application Server, the
related ASPs could be distributed over at least two Hosts. related ASPs could be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 One example of a physical network architecture relevant to SS7
carrier grade operation in the IP network domain is shown in Figure carrier grade operation in the IP network domain is shown in Figure A-
A-1 below: 1 below:
SGs MGCs SGs MGCs
Host#1 ************** ************** Host#3 Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * = * ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1 * *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** * * ******** * \ / * ******** *
* ********__*______\__/________________*__******** * * ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * * * *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** * * ******** * /\ | | * ******** *
skipping to change at page 109, line 51 skipping to change at page 113, line 5
multiple SGPs for transferring traffic to the SS7 network, the ASP multiple SGPs for transferring traffic to the SS7 network, the ASP
must maintain knowledge of the current capability of the SGPs to must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup, crucial to the overall reliability of the service, for active/backup,
loadsharing and broadcast models, in the event of failures, recovery loadsharing and broadcast models, in the event of failures, recovery
and maintenance activities. The ASP M3UA may also use this and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts. minimize message missequencing, as required by the SS7 User Parts.
Appendix B: Changes from RFC3332
outline any backward compatibility issues
Editors' Addresses Editors' Addresses
Ken Morneault Ken Morneault
Cisco Systems Inc. Cisco Systems Inc.
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA, USA 20171 Herndon, VA, USA 20171
EMail: kmorneau@cisco.com EMail: kmorneau@cisco.com
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
C/ Retama 1 C/ Retama 1
28045 Madrid - Spain 28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com EMail: j.javier.pastor@ericsson.com
Full Copyright Statement Intellectual Property
Copyright (C) The Internet Society (2004). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use
and distributed, in whole or in part, without restriction of any of such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository
included on all such copies and derivative works. However, this at http://www.ietf.org/ipr.
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 The IETF invites any interested party to bring to its attention
revoked by the Internet Society or its successors or assigns. any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
This document and the information contained herein is provided on an Full Copyright Statement
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Copyright (C) The Internet Society (2004). This document is subject
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION to the rights, licenses and restrictions contained in BCP 78, and
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF except as set forth therein, the authors retain all their rights.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/