draft-ietf-sigtran-m2ua-07.txt   draft-ietf-sigtran-m2ua-08.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Cisco Systems Cisco Systems
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Tom George Tom George
Alcatel Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Jacob Heitz Jacob Heitz
Lucent Lucent
Expires in six months Feb 2001 Expires in six months June 2001
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-07.txt> <draft-ietf-sigtran-m2ua-08.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups MAY also distribute and its working groups. Note that other groups MAY also distribute
working documents as Internet-Drafts. 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.3 M2UA Messages.........................................11 3.3 M2UA Messages.........................................11
4. Procedures...............................................20 4. Procedures...............................................20
4.1 Procedures to Support Service in Section 1.4.1........20 4.1 Procedures to Support Service in Section 1.4.1........20
4.2 Procedures to Support Service in Section 1.4.2........21 4.2 Procedures to Support Service in Section 1.4.2........21
4.3 Procedures to Support Service in Section 1.4.3........21 4.3 Procedures to Support Service in Section 1.4.3........21
5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26
5.1 Establishment of associations between SG and MGC......26 5.1 Establishment of associations between SG and MGC......26
examples examples
5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28
5.3 Layer Management Communication Examples...............29 5.3 Layer Management Communication Examples...............29
6. Security.................................................30 6. Timers...................................................30
7. IANA Considerations......................................31 7. Security.................................................30
7.1 SCTP Payload Protocol Identifier.......................31 8. IANA Considerations......................................31
7.2 IUA Protocol Extensions................................31 8.1 SCTP Payload Protocol Identifier.......................31
8. Acknowledgements.........................................31 8.2 IUA Protocol Extensions................................31
9. References...............................................32 9. Acknowledgements.........................................31
10. Author's Addresses.......................................33 10. References...............................................32
11. Author's Addresses.......................................33
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network SCN signaling protocol There is a need for Switched Circuit Network SCN signaling protocol
delivery from an Signaling Gateway (SG) to a Media Gateway delivery from an Signaling Gateway (SG) to a Media Gateway
Controller (MGC) or IP Signaling Point (IPSP). The delivery Controller (MGC) or IP Signaling Point (IPSP). The delivery
mechanism SHOULD meet the following criteria: mechanism SHOULD meet the following criteria:
* Support for MTP Level 2 / MTP Level 3 interface boundary * Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG * Support for communication between Layer Management modules on SG
and MGC and MGC
* Support for management of active associations between the SG and MGC * Support for management of SCTP active associations between the SG and
MGC
In other words, the Signaling Gateway will transport MTP Level 3 The SG will terminate up to MTP Level 2 and the MGC will terminate
messages to a Media Gateway Controller (MGC) or IP Signaling Point MTP Level 3 and above. In other words, the SG will transport MTP
(IPSP). In the case of delivery from an SG to an IPSP, both the SG and Level 3 messages over an IP network to a MGC or IPSP.
IPSP function as traditional SS7 nodes using the IP network as a new
type of SS7 link. This allows for full MTP Level 3 message handling
and network management capabilities.
1.2 Terminology 1.2 Terminology
MTP2-User - A protocol that normally uses the services of MTP Level 2 MTP2-User - A protocol that uses the services of MTP Level 2
(i.e. MTP3). (i.e. MTP3).
Interface - For the purposes of this document, an interface is a SS7 Interface - For the purposes of this document, an interface is a SS7
signaling link. signaling link.
Backhaul - Refers to the transport of signaling from the point of Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU) interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not back to the point of call processing (i.e., the MGCU), if this is not
local [4]. local [4].
skipping to change at page 3, line 67 skipping to change at page 3, line 65
MTP Level 3 and call processing for SS7 links terminated by the MTP Level 3 and call processing for SS7 links terminated by the
Signaling Gateways. Practically speaking, an AS is modeled at the SG Signaling Gateways. Practically speaking, an AS is modeled at the SG
as an ordered list of one or more related Application Server Processes as an ordered list of one or more related Application Server Processes
(e.g., primary, secondary, tertiary, ...). (e.g., primary, secondary, tertiary, ...).
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup Server. Examples of Application Server Processes are primary or backup
MGC instances. MGC instances.
Fail-over - The capability to re-route signaling traffic as required Fail-over - The capability to re-route signaling traffic as required
to an alternate Application Server Process, or group of ASPs, within to an alternate Application Server Process within an Application Server
an Application Server in the event of failure or unavailability of a in the event of failure or unavailability of a currently used Application
currently used Application Server Process. Fail-back MAY apply upon Server Process. Fail-back MAY apply upon the return to service of a
the return to service of a previously unavailable Application Server previously unavailable Application Server Process.
Process.
Signaling Link Terminal (SLT) - Refers to the means of performing all Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their of the functions defined at MTP level 2 regardless of their
implementation [2]. implementation [2].
Layer Management - Layer Management is a nodal function in an SG or Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the M2UA layer and a ASP that handles the inputs and outputs between the M2UA layer and a
local management entity. local management entity.
MTP - The Message Transfer Part of the SS7 protocol. MTP - The Message Transfer Part of the SS7 protocol.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
MTP3 - MTP Level 3, the signalling network layer of SS7 MTP3 - MTP Level 3, the signalling network layer of SS7
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Host - The computing platform that the ASP process is running on. Host - The computing platform that the ASP process is running on.
1.3 M2UA Overview 1.3 M2UA Overview
The framework architecture that has been defined for SCN signaling The framework architecture that has been defined for SCN signaling
transport over IP [6] uses multiple components, including a signaling transport over IP [6] uses two components: a signaling common
common transport protocol and an adaptation module to support the transport protocol and an adaptation module to support the services
services expected by a particular SCN signaling protocol from its expected by a particular SCN signaling protocol from its underlying
underlying protocol layer. protocol layer.
Within this framework architecture, this document defines a SCN Within this framework architecture, this document defines a SCN
adaptation module that is suitable for the transport of SS7 MTP2 User adaptation module that is suitable for the transport of SS7 MTP2 User
messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services
of the Stream Control Transmission Protocol [5] as the underlying of the Stream Control Transmission Protocol [5] as the underlying
reliable signaling common transport protocol. reliable signaling common transport protocol.
In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling
is transmitted and received from the PSTN over a standard SS7 network is transmitted and received from the PSTN over a standard SS7 network
interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4] interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4]
to provide reliable transport of the MTP3-User signaling messages to and to provide reliable transport of the MTP3-User signaling messages to and
from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP).
The SG then provides a functional inter-working of transport functions The SG then provides a inter-working of transport functions
with the IP transport, in order to transfer the MTP2-User signaling with the IP transport, in order to transfer the MTP2-User signaling
messages to and from an Application Server Process where the peer MTP2- messages to and from an Application Server Process where the peer MTP2-
User protocol layer exists. User protocol layer exists.
1.3.1 Example - SG to MGC 1.3.1 Example - SG to MGC
In a Signaling Gateway, it is expected that the SS7 signaling is In a Signaling Gateway, it is expected that the SS7 signaling is
received over a standard SS7 network termination, using the SS7 Message received over a standard SS7 network termination, using the SS7 Message
Transfer Part (MTP) to provide transport of SS7 signaling messages to Transfer Part (MTP) to provide transport of SS7 signaling messages to
and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer
skipping to change at page 5, line 57 skipping to change at page 5, line 57
There are scenarios without redundancy requirements and There are scenarios without redundancy requirements and
scenarios in which redundancy is supported below the transport scenarios in which redundancy is supported below the transport
layer. In these cases, the SCTP functions above MAY NOT be a layer. In these cases, the SCTP functions above MAY NOT be a
requirement and TCP can be used as the underlying common requirement and TCP can be used as the underlying common
transport protocol. transport protocol.
1.3.2 Support for the management of SCTP associations between the SG 1.3.2 Support for the management of SCTP associations between the SG
and ASPs and ASPs
The M2UA layer at the SG maintains the availability state of all The M2UA layer at the SG maintains the availability state of all
dynamically registered remote ASPs, in order to manage the SCTP configured ASPs, in order to manage the SCTP associations and the
Associations and the traffic between the SG and ASPs. As well, the traffic between the SG and ASPs. As well, the active/inactive state
active/inactive state of remote ASP(s) are also maintained. Active of remote ASP(s) are also maintained. The Active ASP(s) are the one(s)
ASPs are those currently receiving traffic from the SG. currently receiving traffic from the SG.
The M2UA layer MAY be instructed by local management to establish an The M2UA layer MAY be instructed by local management to establish an
SCTP association to a peer M2UA node. This can be achieved using the M- SCTP association to a peer M2UA node. This can be achieved using the
SCTP ESTABLISH primitive to request, indicate and confirm the M-SCTP ESTABLISH primitive to request, indicate and confirm the
establishment of an SCTP association with a peer M2UA node. establishment of an SCTP association with a peer M2UA node.
The M2UA layer MAY also need to inform local management of the status of The M2UA layer MAY also need to inform local management of the status of
the underlying SCTP associations using the M-SCTP STATUS request and the underlying SCTP associations using the M-SCTP STATUS request and
indication primitive. For example, the M2UA MAY inform local management indication primitive. For example, the M2UA MAY inform local management
of the reason for the release of an SCTP association, determined either of the reason for the release of an SCTP association, determined either
locally within the M2UA layer or by a primitive from the SCTP. locally within the M2UA layer or by a primitive from the SCTP.
Also the M3UA layer may need to inform the local management of the
change in status of an ASP or AS. This may be achieved using the M-ASP
STATUS request or M-AS STATUS request primitives.
1.3.3 Signaling Network Architecture 1.3.3 Signaling Network Architecture
A Signaling Gateway will support the transport of MTP2-User signaling A Signaling Gateway will support the transport of MTP2-User signaling
traffic received from the SS7 network to one or more distributed ASPs traffic received from the SS7 network to one or more distributed ASPs
(e.g., MGCs). Clearly, the M2UA protocol description cannot in itself (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself
meet any performance and reliability requirements for such transport. meet any performance and reliability requirements for such transport.
A physical network architecture is required, with data on the A physical network architecture is required, with data on the
availability and transfer performance of the physical nodes involved in availability and transfer performance of the physical nodes involved in
any particular exchange of information. However, the M2UA protocol MUST any particular exchange of information. However, the M2UA protocol MUST
be flexible enough allow its operation and management in a variety of be flexible enough allow its operation and management in a variety of
physical configurations that will enable Network Operators to meet physical configurations that will enable Network Operators to meet
their performance and reliability requirements. their performance and reliability requirements.
To meet the stringent SS7 signaling reliability and performance To meet the stringent SS7 signaling reliability and performance
requirements for carrier grade networks, these Network Operators SHOULD requirements for carrier grade networks, these Network Operators SHOULD
ensure that there is no single point of failure provisioned in the end- ensure that there is no single point of failure provisioned in the end-
to-end network architecture between an SS7 node and an IP ASP. to-end network architecture between an SS7 node and an IP ASP.
Depending of course on the reliability of the SG and ASP functional Depending of course on the reliability of the SG and ASP functional
elements, this can typically be met by the spreading links in a linkset elements, this can typically be met by the spreading links in a linkset
across SGs, the provision of redundant QOS-bounded IP network paths for across SGs, the provision of redundant QoS-bounded IP network paths for
SCTP Associations between SCTP End Points, and redundant Hosts. The SCTP Associations between SCTP End Points, and redundant Hosts. The
distribution of ASPs within the available Hosts is also important. For a distribution of ASPs within the available Hosts is also important. For
particular Application Server, the related ASPs SHOULD be distributed over a particular Application Server, the related ASPs SHOULD be distributed
at least two Hosts. over at least two Hosts.
An example logical network architecture relevant to carrier-grade An example logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 2 below: operation in the IP network domain is shown in Figure 2 below:
******** ************** ******** **************
* *_________________________________________* ******** * Host1 * *_________________________________________* ******** * Host1
* * _________* * ASP1 * * * * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** * * SG1 * SCTP Associations | * ******** *
* *_______________________ | * * * *_______________________ | * *
******** | | ************** ******** | | **************
| | | |
******** | | ******** | |
* *_______________________________| * *_______________________________|
* * | * * |
* SG2 * SCTP Associations | * SG2 * SCTP Associations |
* *____________ | * *____________ |
* * | | * * | |
******** | | ************** ******** | | **************
| |_________________* ******** * Host2 | |_________________* ******** * Host2
|____________________________* * ASP1 * * |____________________________* * ASP2 * *
* ******** * * ******** *
* * * *
************** **************
. .
. .
. .
Figure 2 - Logical Model Example Figure 2 - Logical Model Example
For carrier grade networks, Operators SHOULD ensure that under failure For carrier grade networks, Operators SHOULD ensure that under failure
skipping to change at page 6, line 43 skipping to change at page 6, line 43
transaction state or be able to pass the call/transaction state between transaction state or be able to pass the call/transaction state between
each other. Also, in the case of ASPs performing call processing, each other. Also, in the case of ASPs performing call processing,
coordination MAY be required with the related Media Gateway to transfer coordination MAY be required with the related Media Gateway to transfer
the MGC control for a particular trunk termination. However, this the MGC control for a particular trunk termination. However, this
sharing or communication is outside the scope of this document. sharing or communication is outside the scope of this document.
1.3.4 ASP Fail-over Model and Terminology 1.3.4 ASP Fail-over Model and Terminology
The M2UA layer supports ASP fail-over functions in order to support a The M2UA layer supports ASP fail-over functions in order to support a
high availability of call and transaction processing capability. All high availability of call and transaction processing capability. All
MTP2-User messages incoming to an SG from the SS7 network are assigned MTP2-User messages incoming to a SG from the SS7 network are assigned
to a unique Application Server, based on the Interface Identifier of to the unique Application Server, based on the Interface Identifier of
the message. the message.
The Application Server is in practical terms a list of all ASPs currently The M2UA layer supports a n+k redundancy model (active-standby,
registered to process MTP2-User messages from certain Interface loadsharing, broadcast) where 1 ASP is the minimum number of redundant
Identifiers. One or more ASPs in the list are normally active (i.e., ASPs required to handle traffic and k ASPs are available to take over
handling traffic) while any others MAY be unavailable or inactive, to be for a failed or unavailable ASP. Note that 1+1 active/standby redundancy
possibly used in the event of failure or unavailability of the active is a subset of this model. A simplex 1+0 model is also supported as a
ASP(s). subset, with no ASP redundancy.
The M2UA fail-over model supports an 1+k redundancy model, where 1 ASPs
is the minimum number of redundant ASPs required to handle traffic and
k ASPs are available to take over for a failed or unavailable ASP.
Note that 1+1 active/standby redundancy is a subset of this model.
A simplex 1+0 model is also supported as a subset, with no ASP
redundancy.
To avoid a single point of failure, it is recommended that a minimum of To avoid a single point of failure, it is recommended that a minimum of
two ASPs be in the list, resident in separate hosts and therefore two ASPs be configured in an AS list, resident in separate hosts and,
available over different SCTP Associations. For example, in the therefore, available over different SCTP associations. For example, in
network shown in Figure 2, all messages for the Interface Identifiers the network shown in Figure 2, all messages for the Interface Identifiers
could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1 could be sent to ASP1 in Host1 or ASP2 in Host2. The AS list at SG1
might look like the following: might look like the following:
Interface Identiers - Application Server #1 Interface Identiers - Application Server #1
ASP1/Host1 - State = Active ASP1/Host1 - State = Active
ASP1/Host2 - State = Inactive ASP2/Host2 - State = Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP1 in Host2 would message for the Interface Identifiers registered. ASP2 in Host2 would
normally be brought to the active state upon failure of, or loss of normally be brought to the active state upon failure of ASP1/Host1.
connectivity to, ASP1/Host1. In this example, both ASPs are Inactive In this example, both ASPs are Inactive or Active, meaning that the
or Active, meaning that the related SCTP association and far-end M2UA related SCTP association and far-end M2UA peer is ready.
peer is ready.
The two ASPs MAY share state information via shared memory, or MAY The two ASPs MAY share state information via shared memory, or MAY
use an ASP to ASP protocol to pass state information. The ASP to ASP use an ASP to ASP protocol to pass state information. The ASP to ASP
protocol is outside the scope of this document. protocol is outside the scope of this document.
1.3.5 Client/Server Model 1.3.5 Client/Server Model
It is recommended that the SG and ASP be able to support both client It is recommended that the SG and ASP be able to support both client
and server operation. The peer endpoints using M2UA SHOULD be and server operation. The peer endpoints using M2UA SHOULD be
configured so that one always takes on the role of client and the configured so that one always takes on the role of client and the
skipping to change at page 7, line 47 skipping to change at page 7, line 46
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA
is 2904. is 2904.
1.4 Services Provided by the M2UA Adaptation Layer 1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
MTP Level 2 to MTP Level 3. MTP Level 2 to MTP Level 3.
This includes the following services:
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables
a seamless, or as seamless as possible, operation of the MTP2-User peers a seamless, or as seamless as possible, operation of the MTP2-User peers
in the SS7 and IP domains. An example of the primitives that must be in the SS7 and IP domains. An example of the primitives that need to be
supported can be found in [7]. supported can be found in [7].
1.4.2 Support for communication between Layer Management modules 1.4.2 Support for communication between Layer Management modules
on SG and MGC on SG and MGC
It is envisioned that the M2UA layer needs to provide some messages that The M2UA layer needs to provide some messages that will facilitate
will facilitate communication between Layer Management modules on the SG communication between Layer Management modules on the SG and MGC.
and MGC. These primitives are shown below:
To facilitate reporting of errors that arise because of backhauling MTP To facilitate reporting of errors that arise because of backhauling MTP
Level 3 scenario, the following primitive is defined: Level 3 scenario, the following primitive is defined:
M-ERROR M-ERROR
The M-ERROR message is used to indicate an error with a received The M-ERROR message is used to indicate an error with a received
M2UA message (e.g., interface identifier value is not known to the SG). M2UA message (e.g., an interface identifier value is not known to the
SG).
1.4.3 Support for management of active associations between SG and MGC 1.4.3 Support for management of active associations between SG and MGC
The M2UA layer on the SG keeps the state of various ASPs it is associated As discussed in Section 1.3.2, the M2UA layer on the SG keeps the state
with. A set of primitives between M2UA layer and the Layer Management of the configured ASPs. A set of primitives between M2UA layer and the
are defined below to help the Layer Management manage the association(s) Layer Management are defined below to help the Layer Management manage
between the SG and the MGC. The M2UA layer can be instructed the association(s) between the SG and the MGC. The M2UA layer can be
by the Layer Management to establish a SCTP association to a peer M2UA instructed by the Layer Management to establish a SCTP association to
node. This procedure can be achieved using the M-SCTP ESTABLISH a peer M2UA node. This procedure can be achieved using the M-SCTP
primitive. ESTABLISH primitive.
M-SCTP ESTABLISH M-SCTP ESTABLISH
The M-SCTP ESTABLISH primitive is used to request, indicate and confirm The M-SCTP ESTABLISH primitive is used to request, indicate and confirm
the establishment of a SCTP association to a peer M2UA node. the establishment of a SCTP association to a peer M2UA node.
M-SCTP RELEASE M-SCTP RELEASE
The M-SCTP RELEASE primitives are used to request, indicate, and The M-SCTP RELEASE primitives are used to request, indicate, and
confirm the release of a SCTP association to a peer M2UA node. confirm the release of a SCTP association to a peer M2UA node.
skipping to change at page 9, line 57 skipping to change at page 9, line 57
only when an ASP sends an ASP Active message for a particular Interface only when an ASP sends an ASP Active message for a particular Interface
Identifier. It MUST be noted, however, that this mapping is dynamic Identifier. It MUST be noted, however, that this mapping is dynamic
and could change at any time due to a change of ASP state. This mapping and could change at any time due to a change of ASP state. This mapping
could even temporarily be invalid, for example during failover of one could even temporarily be invalid, for example during failover of one
ASP to another. Therefore, the SG MUST maintain the states of AS/ASP ASP to another. Therefore, the SG MUST maintain the states of AS/ASP
and reference them during the routing of an messages to an AS/ASP. and reference them during the routing of an messages to an AS/ASP.
An example of the logical view of relationship between SS7 link, An example of the logical view of relationship between SS7 link,
Interface Identifier, AS and ASP in the SG is shown below: Interface Identifier, AS and ASP in the SG is shown below:
/---------------------------------------------------+ /-------------------------------------------------+
/ /------------------------------------------------|--+ / /----------------------------------------------|--+
/ / v | / / v |
/ / +----+ act+-----+ +-------+ -+--+-|+--+- / / +----+ act+-----+ +-------+ -+--+|-+-
SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+- / +----+ | +----+ | +-----+ +-------+ -+--+--+-
/ +->| AS |--+ Streams / +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+ / +----+ | +----+ stb+-----+
SS7 link2-------->|IID |-+ | ASP | SS7 link2-------->|IID |-+ | ASP |
+----+ +-----+ +----+ +-----+
where IID = Interface Identifier where IID = Interface Identifier
Note that an ASP can be in more than one AS. A SG can support more than one AS. An AS can support more than
one Interface Identifier.
1.5.2 Status of ASPs 1.5.2 Status of ASPs
The M2UA layer on the SG MUST maintain the state of the ASPs it is The M2UA layer on the SG MUST maintain the state of the ASPs it is
supporting. The state of an ASP changes because of reception of supporting. The state of an ASP changes because of reception of
peer-to-peer messages (ASPM messages as described in Section 3.3.2) peer-to-peer messages (ASPM messages as described in Section 3.3.2)
or reception of indications from the local SCTP association. ASP or reception of indications from the local SCTP association. ASP
state transition procedures are described in Section 4.3.1. state transition procedures are described in Section 4.3.1.
At a SG, an Application Server list MAY contain active and inactive At a SG, an Application Server list MAY contain active and inactive
ASPs to support ASP fail-over procedures. When, for example, both ASPs to support ASP fail-over procedures. When, for example, both
a primary and a back-up ASP are available, M2UA peer protocol is a primary and a back-up ASP are available, M2UA peer protocol is
required to control which ASP is currently active. The ordered required to control which ASP is currently active. The ordered
list of ASPs within a logical Application Server is kept updated in list of ASPs within a logical Application Server is kept updated in
the SG to reflect the active Application Server Process(es). the SG to reflect the active Application Server Process.
Also the M2UA layer MAY need to inform the local management of the Also the M2UA layer MAY need to inform the local management of the
change in status of an ASP or AS. This can be achieved using the M-ASP change in status of an ASP or AS. This can be achieved using the M-ASP
STATUS or M-AS STATUS primitives. STATUS or M-AS STATUS primitives.
1.5.3 SCTP Specifics 1.5.3 SCTP Specifics
1.5.3.1 SCTP Stream Management 1.5.3.1 SCTP Stream Management
SCTP allows user specified number of streams to be opened during the SCTP allows a user specified number of streams to be opened during
initialization. It is the responsibility of the M2UA layer to ensure initialization of the association. It is the responsibility of the
proper management of these streams. Because of the unidirectional M2UA layer to ensure proper management of these streams. Because of
nature of streams, M2UA layers are not aware of the stream information the unidirectional nature of streams, a M2UA layer is not aware of the
from the peer M2UA layers. Instead, the Interface Identifier is stream information from its peer M2UA layer. Instead, the Interface
in the M2UA message header. Identifier is in the M2UA message header.
The use of SCTP streams within M2UA is recommended in order to minimize The use of SCTP streams within M2UA is recommended in order to minimize
transmission and buffering delay, therefore improving the overall transmission and buffering delay, therefore improving the overall
performance and reliability of the signaling elements. It is performance and reliability of the signaling elements. A separate
recommended that a separate SCTP stream is used for each SS7 link. SCTP stream can be used for each SS7 link. Or, an implementation may
choose to split the SS7 link across several streams based on SLS.
1.5.3.2 SCTP Send Primitive This method may be of particular interest for high speed links (MTP3b)
since high speed links have a 24-bit sequence number and the stream
M2UA shall set the lifetime parameter in the SEND primitive to SCTP sequence number is 16-bits.
when sending a message. When SCTP times out a message, M2UA shall
abort the SCTP association and follow the same procedure as for a
failed SCTP association.
The default value for the lifetime shall be 2 seconds. Some messages, SCTP Stream '0' SHOULD not be used for MTP2 User Adaptation (MAUP)
like STATUS_FLUSH_BUFFERS may need a shorter lifetime. This is for messages (see Section 3) since stream '0' SHOULD onlt be used for ASP
further study. Management (ASPM) messages (see Section 4.3.3).
1.5.4 Seamless SS7 Network Management Interworking 1.5.4 Seamless SS7 Network Management Interworking
The M2UA layer on the SG SHOULD pass an indication of unavailability of The M2UA layer on the SG SHOULD pass an indication of unavailability of
the M2UA-User (MTP3) to the local Layer Management, if the currently the M2UA-User (MTP3) to the local Layer Management, if the currently
active ASP moves from the ACTIVE state. If the AS moves to the DOWN active ASP moves from the ACTIVE state. If the AS moves to the DOWN
state while SS7 links are in-service, the SG SHOULD follow the MTP 2 state while SS7 links are in-service, the SG SHOULD follow the MTP 2
processor outage procedures [2]. processor outage procedures [2].
1.5.5 Flow Control / Congestion 1.5.5 Flow Control / Congestion
It is possible for the M2UA layer to be informed of IP network congestion It is possible for the M2UA layer to be informed of IP network
onset and abatement by means of an implementation-dependent function congestion onset and abatement by means of an implementation-dependent
(i.e. an indication from the SCTP). function (i.e. an indication from the SCTP). The handling of
this congestion indication by M2UA is implementation dependent.
If the M2UA layer on the SG receives an IP network congestion onset
indication, the M2UA layer SHOULD inform the MTP2 layer of a Local
Processor Outage. When the M2UA layer on the SG receives an IP network
congestion abate indication, the M2UA layer SHOULD inform the MTP2 layer
of a Local Processor Outage condition has been cleared.
If the M2UA layer on the ASP receives an IP network congestion onset
indication, the M2UA layer SHOULD inform the MTP3 layer of a Local
Processor Outage. When the M2UA layer on the ASP receives an IP network
congestion abate indication, the M2UA layer SHOULD inform the MTP3 layer
of a Local Processor Outage condition has been cleared.
1.5.6 Audit of Link State 1.5.6 Audit of Link State
After a failover of one ASP to another ASP, it may be necessary for the After a failover of one ASP to another ASP, it may be necessary for the
M2UA on the ASP to audit the current SS7 link state to ensure consistency. M2UA on the ASP to audit the current SS7 link state to ensure consistency.
The M2UA on the SG would respond to the audit request with information The M2UA on the SG would respond to the audit request with information
regarding the current state of the link (i.e. in-service, out-of-service, regarding the current state of the link (i.e. in-service, out-of-service,
congestion state, LPO/RPO state). congestion state, LPO/RPO state).
1.6 Definition of the M2UA Boundaries 1.6 Definition of the M2UA Boundaries
skipping to change at page 10, line 101 skipping to change at page 10, line 101
Purpose: ASP or SG reports that it has received an ERROR Purpose: ASP or SG reports that it has received an ERROR
message from its peer. message from its peer.
M-ASP-UP request M-ASP-UP request
Direction: LM -> M2UA Direction: LM -> M2UA
Purpose: LM requests ASP to start its operation and send an ASP UP Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SG. message to the SG.
M-ASP-UP confirm M-ASP-UP confirm
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP UP Acknowledgement Purpose: ASP reports that it has received an ASP UP Acknowledgement
message from the SG. message from the SG.
M-ASP-DOWN request M-ASP-DOWN request
Direction: LM -> M2UA Direction: LM -> M2UA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SG. message to the SG.
M-ASP-DOWN confirm M-ASP-DOWN confirm
Direction: M2UA -> LM Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP DOWN Acknowledgement Purpose: ASP reports that is has received an ASP DOWN Acknowledgement
skipping to change at page 11, line 72 skipping to change at page 11, line 72
5 Release Confirm 5 Release Confirm
6 Release Indication 6 Release Indication
7 State Request 7 State Request
8 State Confirm 8 State Confirm
9 State Indication 9 State Indication
10 Data Retrieval Request 10 Data Retrieval Request
11 Data Retrieval Confirm 11 Data Retrieval Confirm
12 Data Retrieval Indication 12 Data Retrieval Indication
13 Data Retrieval Complete Indication 13 Data Retrieval Complete Indication
14 Congestion Indication 14 Congestion Indication
15 TTC Data 15 to 127 Reserved by the IETF
16 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MAUP extensions 128 to 255 Reserved for IETF-Defined MAUP extensions
Application Server Process State Maintenance (ASPSM) messages Application Server Process State Maintenance (ASPSM) messages
0 Reserved 0 Reserved
1 ASP Up (UP) 1 ASP Up (UP)
2 ASP Down (DOWN) 2 ASP Down (DOWN)
3 Reserved 3 Reserved
4 ASP Up Ack (UP ACK) 4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK) 5 ASP Down Ack (DOWN ACK)
6 Reserved 6 Reserved
skipping to change at page 12, line 61 skipping to change at page 12, line 61
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length | | Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Parameter Value / / Parameter Value /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory paramters MUST be placed before optional parameters in a
message.
Parameter Tag: 16 bits (unsigned integer) Parameter Tag: 16 bits (unsigned integer)
The Type field is a 16 bit identifier of the type of parameter. It takes The Type field is a 16 bit identifier of the type of parameter. It
a value of 0 to 65534. takes a value of 0 to 65534. The common parameter Tags (used by all
User Adaptation layers) defined are as follows:
The value of 65535 is reserved for IETF-defined extensions. Values Parameter Value Parameter Name
other than those defined in specific parameter description are reserved --------------- --------------
for use by the IETF. 0 (0x0) Reserved
1 (0x1) Interface Identifier (Integer)
2 (0x2) Interface Identifier (Integer Range)
3 (0x3) Interface Identifier (Text)
4 (0x4) Info String
5 (0x5) Unused
6 (0x6) Unused
7 (0x7) Diagnostic Information
8 (0x8) Heartbeat Data
9 (0x9) Unused
10 (0xa) Reason
11 (0xb) Traffic Mode Type
12 (0xc) Error Code
13 (0xd) Status Type/Information
14 (0xe) ASP Identifier
The M2UA specific parameter Tags defined are as follows:
Parameter Value Parameter Name
--------------- --------------
768 (0x0300) Protocol Data 1
769 (0x0301) Protocol Data 2 (TTC)
770 (0x0302) State Request
771 (0x0303) State Result
772 (0x0304) State Event
773 (0x0305) Congestion Status
774 (0x0306) Discard Status
775 (0x0307) Action
776 (0x0308) Sequence Number
777 (0x0309) Retrieval Result
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in bytes, The Parameter Length field contains the size of the parameter in bytes,
including the Parameter Tag, Parameter Length, and Parameter Value including the Parameter Tag, Parameter Length, and Parameter Value
fields. The Parameter Length does not include any padding bytes. fields. The Parameter Length does not include any padding bytes.
Parameter Value: variable-length. Parameter Value: variable-length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
skipping to change at page 12, line 99 skipping to change at page 12, line 132
3.2 M2UA Message Header 3.2 M2UA Message Header
In addition to the common message header, there will be a M2UA specific In addition to the common message header, there will be a M2UA specific
message header. The M2UA specific message header will immediately message header. The M2UA specific message header will immediately
follow the common message header, but will only be used with MAUP follow the common message header, but will only be used with MAUP
messages. messages.
This message header will contain the Interface Identifier. The This message header will contain the Interface Identifier. The
Interface Identifier identifies the physical interface at the SG for Interface Identifier identifies the physical interface at the SG for
which the signaling messages are sent/received. The format of the which the signaling messages are sent/received. The format of the
Interface Identifier parameter can be text or integer, the values of which Interface Identifier parameter can be text or integer, the values of
are assigned according to network operator policy. The values used are of which are assigned according to network operator policy. The values
local significance only, coordinated between the SG and ASP. used are of local significance only, coordinated between the SG and
ASP.
The integer formatted Interface Identifier MUST be supported. The The integer formatted Interface Identifier MUST be supported. The
text formatted Interface Identifier MAY optionally be supported. text formatted Interface Identifier MAY optionally be supported.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length=8 | | Tag (0x1) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) | | Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 M2UA Message Header (Integer-based Interface Identifier) Figure 4 M2UA Message Header (Integer-based Interface Identifier)
The Tag value for Integer-based Interface Identifier is 0x1. The length is The Tag value for Integer-based Interface Identifier is 0x1. The length
always set to a value of 8. is always set to a value of 8.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length | | Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (text) | | Interface Identifier (text) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 147 skipping to change at page 12, line 181
M2UA messages will use the common message header (Figure 3) and the M2UA messages will use the common message header (Figure 3) and the
M2UA message header (Figure 4). M2UA message header (Figure 4).
3.3.1 MTP2 User Adaptation Messages 3.3.1 MTP2 User Adaptation Messages
3.3.1.1 Data 3.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The
Data message contains the following parameter: Data message contains the following parameter:
Protocol Data (Mandatory) Protocol Data (mandatory)
The format for the Data Message parameters is as follows: The format for the Data Message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length | | Tag (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data | | Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in The Protocol Data field contains the MTP2-User application message in
network byte order starting with the Signaling Information Octet (SIO). network byte order starting with the Signaling Information Octet (SIO).
3.3.1.2 TTC Data The format for a Data Message with TTC PDU parameters is as follows:
The TTC Data message contains a TTC SS7 MTP2-User Protocol Data Unit
(PDU). The TTC Data message contains the following parameter:
Protocol Data (Mandatory)
The format for the TTC Data Message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xf) | Length | | Tag (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data | | Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in The Protocol Data field contains the MTP2-User application message in
network byte order starting with the Length Indicator (LI) octet. network byte order starting with the Length Indicator (LI) octet.
The Japanese TTC variant uses the spare bits of the LI octet for The Japanese TTC variant uses the spare bits of the LI octet for
priority. priority.
3.3.1.3 Establish (Request, Confirmation) 3.3.1.2 Establish (Request, Confirmation)
The Establish Request message is used to establish the link or to The Establish Request message is used to establish the link or to
indicate that the channel has been established. The MGC controls the indicate that the channel has been established. The MGC controls the
state of the SS7 link. When the MGC desires the SS7 link to be state of the SS7 link. When the MGC desires the SS7 link to be
in-service, it will send the Establish Request message. Note that the in-service, it will send the Establish Request message. Note that the
gateway MAY already have the SS7 link established at its layer. If so, gateway MAY already have the SS7 link established at its layer. If so,
upon receipt of an Establish Request, the gateway takes no action except upon receipt of an Establish Request, the gateway takes no action except
to send an Establish Confirm. to send an Establish Confirm.
When the MGC sends an M2UA Establish Request message, the MGC MAY When the MGC sends an M2UA Establish Request message, the MGC MAY
start a timer. This timer would be stopped upon receipt of an M2UA start a timer. This timer would be stopped upon receipt of an M2UA
Establish Confirm. If the timer expires, the MGC would re-send the Establish Confirm. If the timer expires, the MGC would re-send the
M2UA Establish Request message and restart the timer. In other words, M2UA Establish Request message and restart the timer. In other words,
the MGC MAY continue to request the establishment of the data link the MGC MAY continue to request the establishment of the data link
on periodic basis until the desired state is achieved or take some on periodic basis until the desired state is achieved or take some
other action (notify the Management Layer). other action (notify the Management Layer).
The mode (Normal of Emergency) for bringing the link in service is The mode (Normal or Emergency) for bringing the link in service is
defaulted to Normal. The State Request (described in Section 3.3.1.4 defaulted to Normal. The State Request (described in Section 3.3.1.4
below) can be used to change the mode to Emergency. below) can be used to change the mode to Emergency.
3.3.1.4 Release (Request, Indication, Confirmation) 3.3.1.3 Release (Request, Indication, Confirmation)
This Release Request message is used to release the channel. The This Release Request message is used to release the channel. The
Release Confirm and Indication messages are used to indicate that the Release Confirm and Indication messages are used to indicate that the
channel has been released. channel has been released.
3.3.1.5 State Request 3.3.1.4 State Request
The State Request message can be sent from a MGC to cause an action The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway. The on a particular SS7 link supported by the Signaling Gateway. The
gateway sends a State Confirm to the MGC if the action has been success- gateway sends a State Confirm to the MGC if the action has been success-
fully completed. The State Confirm reflects that state value received fully completed. The State Confirm reflects that state value received
in the State Request message. in the State Request message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x10) | Length | | Tag (0x302) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
procedure procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure emergency) procedure
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit STATUS_FLUSH_BUFFERS 0x4 Flush receive, transmit and retransmit
buffers queues
STATUS_CONTINUE 0x5 Continue STATUS_CONTINUE 0x5 Continue
STATUS_AUDIT 0x6 Audit state of link STATUS_AUDIT 0x6 Audit state of link
STATUS_CONG_CLEAR 0x7 Congestion cleared
STATUS_CONG_ACCEPT 0x8 Congestion accept
STATUS_CONG_DISCARD 0x9 Congestion discard
3.3.1.5 State Confirm 3.3.1.5 State Confirm
The State Confirm message will be sent by the SG in response to a State The State Confirm message will be sent by the SG in response to a State
Request from the MGC. The State Confirm reflects that state value Request from the MGC. The State Confirm reflects that state value
received in the State Request message. There is also a field to indicate received in the State Request message. There is also a field to indicate
whether or not the the State Request was successfully completed. whether or not the the State Request was successfully completed.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x16) | Length | | Tag (0x302) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x303) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | | Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The value The valid values for State are shown in the following table. The value
of the State field should reflect the value received in the State Request of the State field should reflect the value received in the State Request
message. message.
Define Value Description Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
procedure procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure emergency) procedure
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit STATUS_FLUSH_BUFFERS 0x4 Flush receive, transmit and retransmit
buffers queues
STATUS_CONTINUE 0x5 Continue STATUS_CONTINUE 0x5 Continue
STATUS_AUDIT 0x6 Audit state of link STATUS_AUDIT 0x6 Audit state of link
The valid values for the Result field are shown in the following table. The valid values for the Result field are shown in the following table.
Define Value Description Define Value Description
STATUS_SUCCESS 0x0 Successfully completed Request STATUS_SUCCESS 0x0 Successfully completed Request
STATUS_FAILURE 0x1 Failed to complete Request STATUS_FAILURE 0x1 Failed to complete Request
3.3.1.6 State Indication 3.3.1.6 State Indication
The MTP2 State Indication message can be sent from a gateway to an The MTP2 State Indication message can be sent from a gateway to an
ASP to indicate a condition on a link. ASP to indicate a condition on a link.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x11) | Length | | Tag (0x304) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | | Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Event are shown in the following table. The valid values for Event are shown in the following table.
Define Value Description Define Value Description
EVENT_RPO_ENTER 0x1 Remote entered processor outage EVENT_RPO_ENTER 0x1 Remote entered processor outage
EVENT_RPO_EXIT 0x2 Remote exited processor outage EVENT_RPO_EXIT 0x2 Remote exited processor outage
3.3.1.7 Congestion Indication 3.3.1.7 Congestion Indication
The Congestion Indication message can be sent from a gateway to an ASP The Congestion Indication message can be sent from a Signaling Gateway
to indicate the congestion status and discard status of a link. When to an ASP to indicate the congestion status and discard status of a link.
the MSU buffer fill increases above an Onset threshold or decreases below When the MSU buffer fill increases above an Onset threshold or decreases
an Abatement threshold or crosses a Discard threshold in either below an Abatement threshold or crosses a Discard threshold in either
direction, the SG SHALL send a congestion indication message. direction, the SG SHALL send a congestion indication message.
The SG shall send the message only when there is actually a change The SG shall send the message only when there is actually a change
in either the discard level or the congestion level to report, in either the discard level or the congestion level to report,
meaning it is different from the previously sent message. In addition, meaning it is different from the previously sent message. In addition,
the SG SHALL use an implementation dependent algorithm to limit the the SG SHALL use an implementation dependent algorithm to limit the
frequency of congestion indication messages. frequency of congestion indication messages.
An implementation may optionally send Congestion Indication messages on An implementation may optionally send Congestion Indication messages on
a "high priority" stream in order to potentially reduce delay (Refer to a "high priority" stream in order to potentially reduce delay (Refer to
[12] for more details). [12] for more details).
skipping to change at page 14, line 76 skipping to change at page 14, line 79
meaning it is different from the previously sent message. In addition, meaning it is different from the previously sent message. In addition,
the SG SHALL use an implementation dependent algorithm to limit the the SG SHALL use an implementation dependent algorithm to limit the
frequency of congestion indication messages. frequency of congestion indication messages.
An implementation may optionally send Congestion Indication messages on An implementation may optionally send Congestion Indication messages on
a "high priority" stream in order to potentially reduce delay (Refer to a "high priority" stream in order to potentially reduce delay (Refer to
[12] for more details). [12] for more details).
The Congestion Indication message contains the following parameters: The Congestion Indication message contains the following parameters:
Congestion Status (Mandatory) Congestion Status (mandatory)
Discard Status (Optional) Discard Status (optional)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x15) | Length | | Tag (0x305) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Status | | Congestion Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x306) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Status | | Discard Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Congestion Status and Discard Status are shown in The valid values for Congestion Status and Discard Status are shown in
the following table. the following table.
Define Value Description Define Value Description
LEVEL_NONE 0x0 No congestion. LEVEL_NONE 0x0 No congestion.
LEVEL_1 0x1 Congestion Level 1 LEVEL_1 0x1 Congestion Level 1
LEVEL_2 0x2 Congestion Level 2 LEVEL_2 0x2 Congestion Level 2
LEVEL_3 0x3 Congestion Level 3 LEVEL_3 0x3 Congestion Level 3
LEVEL_4 0x4 Discarding
For networks that do not support multiple levels of congestion, only the For networks that do not support multiple levels of congestion, only the
LEVEL_NONE and LEVEL_1 values will be used. For networks that support LEVEL_NONE and LEVEL_3 values will be used. For networks that support
multiple levels of congestion, it is possible for all values to be used. multiple levels of congestion, it is possible for all values to be used.
Refer to [2] and [9] for more details. Refer to [2] and [9] for more details.
3.3.1.8 Retrieval (Request, Confirm) When the SG runs out of buffer space for MSUs received from the MGC, the
SG shall send a Congestion Indication message with Congestion Status and
Discard Status set to LEVEL_DISCARDING and discard MSUs received from the
MGC.
3.3.1.8 Retrieval Request
The MTP2 Retrieval Request message is used during the MTP Level 3 The MTP2 Retrieval Request message is used during the MTP Level 3
changeover procedure to request the BSN, to retrieve PDUs from the changeover procedure to request the BSN, to retrieve PDUs from the
retransmit queue or to flush PDUs from the retransmit queue. transmit and retransmit queues or to flush PDUs from the retransmit
queue.
The Retrieval Request message contains the following parameters:
Action (mandatory)
Sequence Number (optional)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x12) | Length | | Tag (0x307) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length | | Tag (0x308) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seq_num | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are shown in the following table. The valid values for Action are shown in the following table.
Define Value Description Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit
queue queue
ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue
ACTION_RTRV_TRANS 0x4 Retrieve the PDUs from the transmit
queue
In the Retrieval Request message, the seq_num field SHOULD be ignored if In the Retrieval Request message, the Sequence Number field SHOULD NOT
the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The seq_num be present if the Action field is ACTION_RTRV_BSN, ACTION_DROP_MSGS or
field contains the Forward Sequnce Number (FSN) of the far end if the ACTION_RTRV_TRANS. The Sequence Number field contains the Forward
Action is ACTION_RTRV_MSGS. Sequnce Number (FSN) of the far end if the Action is ACTION_RTRV_MSGS.
When the Signaling Gateway sends a Retrieval Confirm to this request, 3.3.1.9 Retrieval Confirm
it echos the action and puts the Backward Sequence Number (BSN) in the
seq_num field if the action was ACTION_RTRV_BSN. If there is a failure
in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff).
For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of
of seq_num will be set to zero for success or -1 (0xffffffff) for failure.
A failure means that the buffers could not be retrieved. For a Retrieval
Confirm with an Action of ACTION_DROP_MSGS, the value received in the
seq_num field will be ignored.
3.3.1.9 Retrieval Indication The MTP2 Retrieval Confirm message is sent by the Signaling Gateway
in response to a Retrieval Request message.
The Retrieval Indication message is sent by the Signaling Gateway The Retrieval Confirm message contains the following parameters:
with a PDU from the retransmit queue. The Retrieval Indication
Action (mandatory)
Result (mandatory)
Sequence Number (optional)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x309) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x308) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are the same as in Retrieval Request.
The values for Result are shown below: in the following table.
Define Value Description
RESULT_SUCCESS 0x0 Action successful
RESULT_FAILURE 0x1 Action failed
When the Signaling Gateway sends a Retrieval Confirm to a Retrieval
Request, it echos the Action field. If the Action was ACTION_RTRV_BSN
and the SG successfully retrieved the BSN, the SG will put the Backward
Sequence Number (BSN) in the Sequence Number field and will indicate a
success in the Result field. If the BSN could not be retrieved, the
Sequence Number field will not be included and the Result field will
indicate failure.
For a Retrieval Confirm with Action of ACTION_RTRV_MSGS and
ACTION_RTRV_TRANS, the value of of Result field will indicate success or
failure. A failure means that the buffers could not be retrieved. The
Sequence Number field is not used with ACTION_RTRV_MSGS.
For a Retrieval Confirm with an Action of ACTION_DROP_MSGS, the Result
value will indicate success or failure. The Sequence Number field is
not used with ACTION_DROP_MSGS.
3.3.1.10 Retrieval Indication
The Retrieval Indication message is sent by the Signaling Gateway with a
PDU from the transmit or retransmit queue. The Retrieval Indication
message does not contain the Action or seq_num fields, just a MTP3 message does not contain the Action or seq_num fields, just a MTP3
Protocol Data Unit (PDU) from the retransmit queue. Protocol Data Unit (PDU) from the transmit or retransmit queue.
The M2UA implementation MAY consider the use of the bundling feature 0 1 2 3
of SCTP for Retrieval Indication messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU from transmit or retransmit queue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For TTC Data messages, the following parameter will be used to indicate
a TTC PDU which starts at LI.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x14) | Length | | Tag (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU from retransmit queue | | TTC PDU from transmit or retransmit queue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.1.10 Retrieval Complete Indication The M2UA implementation MAY consider the use of the bundling feature
of SCTP for Retrieval Indication messages.
3.3.1.11 Retrieval Complete Indication
The MTP2 Retrieval Complete Indication message is exactly the same as The MTP2 Retrieval Complete Indication message is exactly the same as
the MTP2 Retrieval Indication message except that it also indicates that the MTP2 Retrieval Indication message except that it also indicates that
it contains the last PDU from the retransmit queue. it contains the last PDU from the transmit or retransmit queue.
3.3.2 Application Server Process Maintenance (ASPM) Messages 3.3.2 Application Server Process Maintenance (ASPM) Messages
The ASPM messages will only use the common message header. The ASPM messages will only use the common message header.
3.3.2.1 ASP UP (ASPUP) 3.3.2.1 ASP UP (ASPUP)
The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer
that the Adaptation layer is ready to receive traffic or maintenance that the Adaptation layer is ready to receive traffic or maintenance
messages. messages.
The ASPUP message contains the following parameters The ASPUP message contains the following parameters
ASP Identifier (optional)
Info String (optional) Info String (optional)
The format for ASPUP Message parameters is as follows: The format for ASPUP Message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter would contain a unique value
that is locally significant to the ASPs that support an AS. The SG
would save the ASP Identifier to be used, if necessary, with the
Notify message (see Section 3.3.3.2).
The optional INFO String parameter can carry any meaningful 8-bit ASCII The optional INFO String parameter can carry any meaningful 8-bit ASCII
character string along with the message. Length of the INFO String character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently parameter is from 0 to 255 characters. No procedures are presently
identified for its use but the INFO String MAY be used for debugging identified for its use but the INFO String MAY be used for debugging
purposes. purposes.
3.3.2.2 ASP Up Ack 3.3.2.2 ASP Up Ack
The ASP UP Ack message is used to acknowledge an ASP Up message received The ASP UP Ack message is used to acknowledge an ASP Up message received
from a remote M2UA peer. from a remote M2UA peer.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP UP message (See Section 3.3.2.1.) same as for the ASP UP message (See Section 3.3.2.1).
3.3.2.3 ASP Down (ASPDN) 3.3.2.3 ASP Down (ASPDN)
The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer
that the adaptation layer is not ready to receive traffic or that the adaptation layer is not ready to receive traffic or
maintenance messages. maintenance messages.
The ASPDN message contains the following parameters The ASPDN message contains the following parameters
Reason Reason
INFO String (Optional) INFO String (optional)
The format for the ASPDN message parameters is as follows: The format for the ASPDN message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length | | Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP Up message (See Section 3.3.2.1.). same as for the ASP Up message (See Section 3.3.2.1).
The Reason parameter indicates the reason that the remote M2UA The Reason parameter indicates the reason that the remote M2UA
adaptation layer is unavailable. The valid values for Reason are shown adaptation layer is unavailable. The valid values for Reason are shown
in the following table. in the following table.
Value Description Value Description
0x1 Management 0x1 Management
3.3.2.4 ASP Down Ack 3.3.2.4 ASP Down Ack
The ASP Down Ack message is used to acknowledge an ASP Down message The ASP Down Ack message is used to acknowledge an ASP Down message
received from a remote M2UA peer. received from a remote M2UA peer.
The ASP Down Ack message contains the following parameters: The ASP Down Ack message contains the following parameters:
Reason Reason
INFO String (Optional) INFO String (optional)
The format for the ASPDN Ack message parameters is as follows: The format for the ASPDN Ack message parameters is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xa) | Length | | Tag (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP UP message (See Section 3.3.2.1.) same as for the ASP UP message (See Section 3.3.2.1).
The format of the Reason parameter is the same as for the ASP Down message The format of the Reason parameter is the same as for the ASP Down message
(See Section 3.3.2.3). (See Section 3.3.2.3).
3.3.2.5 ASP Active (ASPAC) 3.3.2.5 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is The ASPAC message is sent by an ASP to indicate to an SG that it is
Active and ready to be used. Active and ready to be used.
The ASPAC message contains the following parameters The ASPAC message contains the following parameters
Traffic Mode Type (Mandatory) Traffic Mode Type (mandatory)
Interface Identifier (Optional) Interface Identifier (optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (optional)
The format for the ASPAC message using integer formatted Interface The format for the ASPAC message using integer formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length | | Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
skipping to change at page 17, line 191 skipping to change at page 17, line 191
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Traffic Mode Type parameter identifies the traffic mode of The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS. The valid values for Type are operation of the ASP within an AS. The valid values for Type are
shown in the following table: shown in the following table:
Value Description Value Description
0x1 Over-ride 0x1 Over-ride
0x2 Load-share
0x3 Broadcast
Within a particular Interface Identifier, only one Type can be used. Within a particular AS, only one Traffic Mode Type can be used.
The Over-ride value indicates that the ASP is operating in Over-ride The Over-ride value indicates that the ASP is operating in Over-ride
mode, where the ASP takes over all traffic in an Application Server mode, where the ASP takes over all traffic in an Application Server
(i.e., primary/back-up operation), over-riding any currently active (i.e., primary/back-up operation), over-riding any currently active
ASPs in the AS. ASPs in the AS. In Load-share mode, the ASP will share in the traffic
distribution with any other currently active ASPs. In Broadcast mode,
all of the Active ASPs receive all message traffic in the Application
Server.
The optional Interface Identifiers parameter contains a list of The optional Interface Identifiers parameter contains a list of
Interface Identifier integers (Type 0x1 or Type 0x8) or text strings Interface Identifier integers (Type 0x1 or Type 0x8) or text strings
(Type 0x3)indexing the Application Server traffic that the sending (Type 0x3)indexing the Application Server traffic that the sending
ASP is configured/registered to receive. If integer formatted ASP is configured/registered to receive. If integer formatted
Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers are being used, the ASP can also send ranges of
Interface Identifiers (Type 0x8). Interface Identifier types Integer Interface Identifiers (Type 0x8). Interface Identifier types Integer
(0x1) and Integer Range (0x8) are allowed in the same message. Text (0x1) and Integer Range (0x8) are allowed in the same message. Text
formatted Interface Identifiers (0x3) cannot be used with either formatted Interface Identifiers (0x3) cannot be used with either
Integer (0x1) or Integer Range (0x8) types. Integer (0x1) or Integer Range (0x8) types.
skipping to change at page 19, line ? skipping to change at page 19, line ?
If no Interface Identifiers are included, the message is for all If no Interface Identifiers are included, the message is for all
provisioned Interface Identifiers within the AS(s) in which the provisioned Interface Identifiers within the AS(s) in which the
ASP is provisioned. If only a subset of Interface Identifiers are ASP is provisioned. If only a subset of Interface Identifiers are
included, the ASP is noted as Active for all the Interface Identifiers included, the ASP is noted as Active for all the Interface Identifiers
provisioned for that AS. provisioned for that AS.
Note: If the optional Interface Identifier parameter is present, the Note: If the optional Interface Identifier parameter is present, the
integer formatted Interface Identifier MUST be supported, while the integer formatted Interface Identifier MUST be supported, while the
text formatted Interface Identifier MAY be supported. text formatted Interface Identifier MAY be supported.
An SG that receives an ASPAC with an incorrect Traffic Mode Type for An SG that receives an ASPAC with an incorrect or unsupported Traffic
a particular Interface Identifier will respond with an Error Message Mode Type for a particular Interface Identifier will respond with an
(Cause: Unsupported Traffic Handling Mode). Error Message (Cause: Unsupported Traffic Handling Mode).
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP UP message (See Section 3.3.2.1.). same as for the ASP UP message (See Section 3.3.2.1).
3.3.2.6 ASP Active Ack 3.3.2.6 ASP Active Ack
The ASPAC Ack message is used to acknowledge an ASP-Active message The ASPAC Ack message is used to acknowledge an ASP-Active message
received from a remote M2UA peer. received from a remote M2UA peer.
The ASPAC Ack message contains the following parameters: The ASPAC Ack message contains the following parameters:
Traffic Mode Type (Mandatory) Traffic Mode Type (mandatory)
Interface Identifier (Optional) Interface Identifier (optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (optional)
The format for the ASPAC Ack message with Integer-formatted Interface The format for the ASPAC Ack message with Integer-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length | | Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
skipping to change at page 19, line ? skipping to change at page 19, line ?
3.3.2.7 ASP Inactive (ASPIA) 3.3.2.7 ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is no The ASPIA message is sent by an ASP to indicate to an SG that it is no
longer an active ASP to be used from within a list of ASPs. The SG will longer an active ASP to be used from within a list of ASPs. The SG will
respond with an ASPIA Ack message and either discard incoming messages respond with an ASPIA Ack message and either discard incoming messages
or buffer for a timed period and then discard. or buffer for a timed period and then discard.
The ASPIA message contains the following parameters The ASPIA message contains the following parameters
Traffic Mode Type (Mandatory) Traffic Mode Type (mandatory)
Interface Identifiers (Optional) Interface Identifiers (optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (optional)
The format for the ASP Inactive message parameters using Integer The format for the ASP Inactive message parameters using Integer
formatted Interface Identifiers is as follows: formatted Interface Identifiers is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length | | Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
skipping to change at page 19, line ? skipping to change at page 19, line ?
that the sending ASP is configured/registered to receive, but does not that the sending ASP is configured/registered to receive, but does not
want to receive at this time. want to receive at this time.
3.3.2.8 ASP Inactive Ack 3.3.2.8 ASP Inactive Ack
The ASPIA Ack message is used to acknowledge an ASP-Inactive message The ASPIA Ack message is used to acknowledge an ASP-Inactive message
received from a remote M2UA peer. received from a remote M2UA peer.
The ASPIA Ack message contains the following parameters: The ASPIA Ack message contains the following parameters:
Traffic Mode Type (Mandatory) Traffic Mode Type (mandatory)
Interface Identifiers (Optional) Interface Identifiers (optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (optional)
The format for the ASPIA Ack message is as follows: The format for the ASPIA Ack message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xb) | Length | | Tag (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line ? skipping to change at page 19, line ?
3.3.3.1 Error (ERR) 3.3.3.1 Error (ERR)
The Error message is used to notify a peer of an error event The Error message is used to notify a peer of an error event
associated with an incoming message. For example, the message type associated with an incoming message. For example, the message type
might be unexpected given the current state, or a parameter value might might be unexpected given the current state, or a parameter value might
be invalid. be invalid.
The ERR message contains the following parameters: The ERR message contains the following parameters:
Error Code Error Code (mandatory)
Diagnostic Information (optional) Diagnostic Information (optional)
The format for the ERR message is as follows: The format for the ERR message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xc) | Length | | Tag (0xc) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
skipping to change at page 19, line ? skipping to change at page 19, line ?
The Error Code parameter indicates the reason for the Error Message. The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values: The Error parameter value can be one of the following values:
Invalid Version 0x1 Invalid Version 0x1
Invalid Interface Identifier 0x2 Invalid Interface Identifier 0x2
Unsupported Message Class 0x3 Unsupported Message Class 0x3
Unsupported Message Type 0x4 Unsupported Message Type 0x4
Unsupported Traffic Handling Mode 0x5 Unsupported Traffic Handling Mode 0x5
Unexpected Message 0x6 Unexpected Message 0x6
Protocol Error 0x7 Protocol Error 0x7
Invalid Stream Identifier 0x8 Unsupported Interface Identifier Type 0x8
Unsupported Interface Identifier Type 0x9 Invalid Stream Identifier 0x9
The "Invalid Version" error would be sent if a message was The "Invalid Version" error would be sent if a message was
received with an invalid or unsupported version. The Error message received with an invalid or unsupported version. The Error message
would contain the supported version in the Common header. The would contain the supported version in the Common header. The
Error message could optionally provide the supported version in Error message could optionally provide the supported version in
the Diagnostic Information area. the Diagnostic Information area.
The "Invalid Interface Identifier" error would be sent by a SG if The "Invalid Interface Identifier" error would be sent by a SG if
an ASP sends a message with an invalid (unconfigured) Interface an ASP sends a message with an invalid (unconfigured) Interface
Identifier value. Identifier value.
skipping to change at page 19, line ? skipping to change at page 19, line ?
Mode. An example would be a case in which the SG did not support Mode. An example would be a case in which the SG did not support
load-sharing. load-sharing.
The "Unexpected Message" error would be sent by an ASP if it received The "Unexpected Message" error would be sent by an ASP if it received
a MAUP message from an SG while it was in the Inactive state. a MAUP message from an SG while it was in the Inactive state.
The "Protocol Error" error would be sent for any protocol anomaly The "Protocol Error" error would be sent for any protocol anomaly
(i.e. a bogus message). (i.e. a bogus message).
The "Invalid Stream Identifier" error would be sent if a message The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream (i.e. i.e. a MGMT message was received on an unexpected SCTP stream (i.e. a MGMT message
was received on a stream other than "0").). was received on a stream other than "0").
The "Unsupported Interface Identifier Type" error would be sent by The "Unsupported Interface Identifier Type" error would be sent by
a SG if an ASP sends a Text formatted Interface Identifier and the a SG if an ASP sends a Text formatted Interface Identifier and the
SG only supports Integer formatted Interface Identifiers. When SG only supports Integer formatted Interface Identifiers. When
the ASP receives this error, it will need to resend its message with the ASP receives this error, it will need to resend its message with
an Integer formatted Interface Identifier. an Integer formatted Interface Identifier.
The "Unsupported Message Class" error would be sent if a message with The "Unsupported Message Class" error would be sent if a message with
an unexpected or unsupported Message Class is received. an unexpected or unsupported Message Class is received.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
an Integer formatted Interface Identifier. an Integer formatted Interface Identifier.
The optional Diagnostic information can be any information germain to The optional Diagnostic information can be any information germain to
the error condition, to assist in identification of the error condition. the error condition, to assist in identification of the error condition.
In the case of an Invalid Version Error Code the Diagnostic information In the case of an Invalid Version Error Code the Diagnostic information
includes the supported Version parameter. In the other cases, the includes the supported Version parameter. In the other cases, the
Diagnostic information MAY be the first 40 bytes of the offending message. Diagnostic information MAY be the first 40 bytes of the offending message.
3.3.3.2 Notify (NTFY) 3.3.3.2 Notify (NTFY)
The Notify message used to provide an autonomous indication of M2UA The Notify message is used to provide an autonomous indication of M2UA
events to an M2UA peer. events to an M2UA peer.
The NTFY message contains the following parameters: The NTFY message contains the following parameters:
Status Type Status Type (mandatory)
Status Identification Status Information (mandatory)
Interface Identifiers (Optional) ASP Identifier (optional)
INFO String (Optional) Interface Identifiers (optional)
INFO String (optional)
The format for the Notify message with Integer-formatted Interface The format for the Notify message with Integer-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length | | Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification | | Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* | | Interface Identifier Start1* |
skipping to change at page 20, line 71 skipping to change at page 20, line 76
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the Notify message with Text-formatted Interface The format for the Notify message with Text-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xd) | Length | | Tag (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification | | Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
| of Tag Type 0x3 | | of Tag Type 0x3 |
skipping to change at page 20, line 110 skipping to change at page 20, line 119
Type is AS_State_Change the following Status Information values are used: Type is AS_State_Change the following Status Information values are used:
Value Description Value Description
1 Application Server Down (AS_Down) 1 Application Server Down (AS_Down)
2 Application Server Inactive (AS_Inactive) 2 Application Server Inactive (AS_Inactive)
3 Application Server Active (AS_Active) 3 Application Server Active (AS_Active)
4 Application Server Pending (AS_Pending) 4 Application Server Pending (AS_Pending)
These notifications are sent from an SG to an ASP upon a change in status These notifications are sent from an SG to an ASP upon a change in status
of a particular Application Server. The value reflects the new state of of a particular Application Server. The value reflects the new state of
the Application Server. the Application Server. The Interface Identifiers of the AS MAY be
placed in the message if desired.
If the Status Type is Other, then the following Status Information values If the Status Type is Other, then the following Status Information values
are defined: are defined:
Value Description Value Description
1 Insufficient ASP resources active in AS 1 Insufficient ASP resources active in AS
2 Alternate ASP Active 2 Alternate ASP Active
3 ASP Failure
This notification is not based on the SG reporting the state change of an In the Insufficent ASP Resources case, the SG is indicating to an
ASP or AS. In the Insufficient ASP Resources case, the SG is "Inactive" ASP(s) in the AS that another ASP is required in order to
indicating to an "Inactive" ASP(s) in the AS that another ASP is handle the load of the AS (Load-sharing mode). For the Alternate ASP
required in order to handle the load of the AS (Load-sharing mode). Active case, the formerly Active ASP is informed when an alternate
For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-Active state in Over-ride mode. The ASP
ASP transitions to the ASP-Active state in Over-ride mode. ID (if available) of the Alternate ASP MUST be placed in the message.
For the ASP Failure case, the SG is indicating to ASP(s) in the AS
that one of the ASPs has failed (i.e. the ASP Transition to Down due
to SCTP Communication Down Indication). The ASP ID (if available) of
the failed ASP MUST be placed in the message.
For each of the Status Information values in Status Type Other, the
Interface Identifiers of the affected AS MAY be placed in the message
if desired.
The format and description of the optional Interface Identifiers and The format and description of the optional Interface Identifiers and
Info String parameters is the same as for the ASP Active message Info String parameters is the same as for the ASP Active message
(See Section 3.3.2.3.) (See Section 3.3.2.3).
4.0 Procedures 4.0 Procedures
The M2UA layers needs to respond to various primitives it receives from The M2UA layer needs to respond to various primitives it receives from
other layers as well as messages it receives from the peer-to-peer other layers as well as messages it receives from the peer-to-peer
messages. This section describes various procedures involved in messages. This section describes various procedures involved in
response to these events. response to these events.
4.1 Procedures to Support Service in Section 1.4.1 4.1 Procedures to Support Service in Section 1.4.1
These procedures achieve the M2UA layer's "Transport of MTP Level 2 / These procedures achieve the M2UA layer's "Transport of MTP Level 2 /
MTP Level 3 boundary" service. MTP Level 3 boundary" service.
4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures
On receiving a primitive from the local upper layer, the M2UA layer will On receiving a primitive from the local upper layer, the M2UA layer will
send the corresponding MAUP message (see Section 2) to its peer. The send the corresponding MAUP message (see Section 3) to its peer. The
M2UA layer MUST fill in various fields of the common and specific headers M2UA layer MUST fill in various fields of the common and specific headers
correctly. In addition the message needs to be sent on the SCTP stream correctly. In addition the message SHOULD to be sent on the SCTP stream
that corresponds to the SS7 link. that corresponds to the SS7 link.
4.1.2 MAUP Message Procedures 4.1.2 MAUP Message Procedures
On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an
SG or MGC needs to invoke the corresponding layer primitives to the SG or MGC needs to invoke the corresponding layer primitives to the
local MTP Level 2 or MTP Level 3 layer. local MTP Level 2 or MTP Level 3 layer.
4.2 Procedures to Support Service in Section 1.4.2 4.2 Procedures to Support Service in Section 1.4.2
These procedures achieve the M2UA layer's "Support for Communication These procedures achieve the M2UA layer's "Support for Communication
between Layer Managements" service. between Layer Managements" service.
4.2.1 Layer Management Primitives Procedure 4.2.1 Layer Management Primitives Procedure
On receiving these primitives from the local layer, the M2UA layer will On receiving primitives from the local Layer Management, the M2UA layer
send the corresponding MGMT message (Error) to its peer. The M2UA layer will take the requested action and provide an appropriate response
MUST fill in the various fields of the common and specific headers primitive to Layer Management.
correctly.
An M-SCTP ESTABLISH request from Layer Management will initiate the An M-SCTP ESTABLISH request from Layer Management will initiate the
establishment of an SCTP association. An M-SCTP ESTABLISH confirm establishment of an SCTP association. An M-SCTP ESTABLISH confirm
will be sent to Layer Management when the initiated association set-up will be sent to Layer Management when the initiated association set-up
is complete. An M-SCTP ESTABLISH indication is sent to Layer is complete. An M-SCTP ESTABLISH indication is sent to Layer
Management upon successful completion of an incoming SCTP association Management upon successful completion of an incoming SCTP association
set-up from a peer M2UA node set-up from a peer M2UA node
An M-SCTP RELEASE request from Layer Management will initiate the An M-SCTP RELEASE request from Layer Management will initiate the
tear-down of an SCTP association. An M-SCTP RELEASE confirm will tear-down of an SCTP association. An M-SCTP RELEASE confirm will
skipping to change at page 22, line 73 skipping to change at page 22, line 72
based on local M2UA events. based on local M2UA events.
All MGMT messages are sent on a sequenced stream to ensure ordering. All MGMT messages are sent on a sequenced stream to ensure ordering.
SCTP stream '0' SHOULD be used. SCTP stream '0' SHOULD be used.
4.3 Procedures to Support Service in Section 1.4.3 4.3 Procedures to Support Service in Section 1.4.3
These procedures achieve the M2UA layer's "Support for management of These procedures achieve the M2UA layer's "Support for management of
active associations between SG and MGC" service. active associations between SG and MGC" service.
4.3.1 State Maintenance 4.3.1 AS and ASP State Maintenance
The M2UA layer on the SG maintains the state of each AS, in each The M2UA layer on the SG maintains the state of each ASP, in each
Appliction Server that it is configured to receive traffic. Appliction Server that is configured to receive traffic.
4.3.1.1 ASP States 4.3.1.1 ASP States
The state of the each ASP, in each AS that it is configured, is The state of the each ASP, in each AS that it is configured, is
maintained in the M2UA layer on the SG. The state of an ASP changes maintained in the M2UA layer on the SG. The state of an ASP changes
due to events. The events include due to events. The events include
* Reception of messages from peer M2UA layer at that ASP * Reception of messages from peer M2UA layer at that ASP
* Reception of some messages from the peer M2UA layer at other * Reception of some messages from the peer M2UA layer at other
ASPs in the AS ASPs in the AS
skipping to change at page 22, line 100 skipping to change at page 22, line 99
states of an ASP are the following: states of an ASP are the following:
ASP Down: Application Server Process is unavailable and/or the related ASP Down: Application Server Process is unavailable and/or the related
SCTP association is down. Initially all ASPs will be in this state. SCTP association is down. Initially all ASPs will be in this state.
An ASP in this state SHOULD NOT not be sent any M2UA messages. An ASP in this state SHOULD NOT not be sent any M2UA messages.
ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the
related SCTP association is up) but application traffic is stopped. related SCTP association is up) but application traffic is stopped.
In this state the ASP can be sent any non-MAUP M2UA messages. In this state the ASP can be sent any non-MAUP M2UA messages.
ASP-ACTIVE The remote M2UA peer at the ASP is available and ASP-ACTIVE: The remote M2UA peer at the ASP is available and
application traffic is active. application traffic is active.
Figure 6 ASP State Transition Diagram Figure 6 ASP State Transition Diagram
+-------------+ +-------------+
+----------------------| | +----------------------| |
| Alternate +-------| ASP-ACTIVE | | Alternate +-------| ASP-ACTIVE |
| ASP | +-------------+ | ASP | +-------------+
| Takeover | ^ | | Takeover | ^ |
| | ASP | | ASP | | ASP | | ASP
skipping to change at page 22, line 134 skipping to change at page 23, line 4
+-------------+ +-------------+
SCTP CDI: The local SCTP layer's Communication Down Indication to the SCTP CDI: The local SCTP layer's Communication Down Indication to the
Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this
indication when it detects the loss of connectivity to the ASP's peer indication when it detects the loss of connectivity to the ASP's peer
SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE SCTP layer. SCTP CDI is understood as either a SHUTDOWN COMPLETE
notification and COMMUNICATION LOST notification from the SCTP. notification and COMMUNICATION LOST notification from the SCTP.
When an SCTP association fails at the SG, M2UA shall change the states When an SCTP association fails at the SG, M2UA shall change the states
of all ASPs reached through the aborted SCTP association to ASP-DOWN. of all ASPs reached through the aborted SCTP association to ASP-DOWN.
When an SCTP association fails at the ASP, M2UA shall either cause other
ASPs to become active or send link-out-of-service primitives to MTP3.
4.3.1.2 AS States 4.3.1.2 AS States
The state of the AS is maintained in the M2UA layer on the SG. The state of the AS is maintained in the M2UA layer on the SG.
The state of an AS changes due to events. These events include the The state of an AS changes due to events. These events include the
following: following:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
skipping to change at page 24, line 41 skipping to change at page 24, line 41
can communicate the status of an SCTP association using the can communicate the status of an SCTP association using the
M-SCTP STATUS primitives. M-SCTP STATUS primitives.
If the Layer Management on SG or ASP wants to bring down an SCTP If the Layer Management on SG or ASP wants to bring down an SCTP
association for management reasons, they would send M-SCTP RELEASE association for management reasons, they would send M-SCTP RELEASE
request primitive to the local M2UA layer. The M2UA layer would release request primitive to the local M2UA layer. The M2UA layer would release
the SCTP association and upon receiving the SCTP Communication Down the SCTP association and upon receiving the SCTP Communication Down
indication from the underlying SCTP layer, it would inform the local indication from the underlying SCTP layer, it would inform the local
Layer Management using M-SCTP RELEASE confirm primitive. Layer Management using M-SCTP RELEASE confirm primitive.
If the M2UA layer receives an SCTP-Communication Down indication If the M2UA layer receives an SCTP-Communication Down or Restart
from the underlying SCTP layer, it will inform the Layer indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP RELEASE indication primitive. The Management by invoking the M-SCTP RELEASE indication primitive. At the
state of the ASP will be moved to "Down" at both the SG and ASP. SG, M2UA shall change the states of all ASPs reached through the aborted
SCTP association to ASP-DOWN. Athe ASP, M2UA shall either cause other
ASPs to become active or send link-out-of-service primitives to MTP3.
At an ASP, the Layer Management MAY try to reestablish the SCTP At an ASP, the Layer Management MAY try to reestablish the SCTP
association using M-SCTP ESTABLISH request primitive. association using M-SCTP ESTABLISH request primitive.
4.3.3 ASPM procedures for peer-to-peer messages 4.3.3 ASPM procedures for peer-to-peer messages
All ASPM messages are sent on a sequenced stream to ensure ordering. All ASPM messages are sent on a sequenced stream to ensure ordering.
SCTP stream '0' SHOULD is used. SCTP stream '0' SHOULD be used.
4.3.3.1 ASP-Inactive 4.3.3.1 ASP-Inactive
After an ASP has successfully established an SCTP association to an SG, After an ASP has successfully established an SCTP association to an SG,
the SG waits for the ASP to send an ASP Up message, indicating that the the SG waits for the ASP to send an ASP Up message, indicating that the
ASP M2UA peer is available. The ASP is always the initiator of the ASP M2UA peer is available. The ASP is always the initiator of the
ASP Up exchange. ASP Up exchange.
When an ASP Up message is received at an SG and internally the ASP is When an ASP Up message is received at an SG and internally the ASP is
not considered locked-out for local management reasons, the SG marks not considered locked-out for local management reasons, the SG marks
the remote ASP as Inactive. The SG responds with an ASP Up Ack message the remote ASP as Inactive. If the ASP UP message contains an ASP
in acknowledgement. The SG sends an-Up Ack message in response to a Identifier, the SG saves the ASP Identifier for that ASP. The SG
received ASP Up message even if the ASP is already marked as "Inactive" responds with an ASP Up Ack message in acknowledgement. The SG sends
at the SG. an ASP Up Ack message in response to a received ASP Up message even if
the ASP is already marked as "Inactive" at the SG.
If for any local reason the SG cannot respond with an ASP Up, the SG If for any local reason the SG cannot respond with an ASP Up Ack, the
responds to a ASP Up with a ASP Down Ack message. SG responds to the ASP Up with a ASP Down Ack message.
When the ASP sends an ASP Up it starts timer T(ack). If the ASP does When the ASP sends an ASP Up it starts timer T(ack). If the ASP does
not receive a response to an ASP Up within T(ack), the ASP MAY restart not receive a response to an ASP Up within T(ack), the ASP MAY restart
T(ack) and resend ASP Up messages until it receives an ASP Up Ack T(ack) and resend ASP Up messages until it receives an ASP Up Ack
message. T(ack) SHOULD be provisionable, with a default of 2 seconds. message. T(ack) SHOULD be provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP Up messages MAY be put under Alternatively, retransmission of ASP Up messages MAY be put under
control of Layer Management. In this method, expiry of T(ack) results control of Layer Management. In this method, expiry of T(ack) results
in a M-ASP-Up confirmation carrying a negative indication. in a M-ASP-Up confirmation carrying a negative indication.
The ASP MUST wait for the ASP Up Ack message from the SG before The ASP MUST wait for the ASP Up Ack message from the SG before
sending any ASP traffic control messages (ASPAC or ASPIA) or Data sending any ASP traffic control messages (ASPAC or ASPIA) or MAUP
messages or it will risk message loss. If the SG receives Data messages or it will risk message loss. If the SG receives MAUP
messages before an ASP Up is received, the SG SHOULD discard. messages before an ASP Up is received, the SG SHOULD discard them.
4.3.3.2 ASP Down 4.3.3.2 ASP Down
The ASP will send an ASP Down to an SG when the ASP is to be removed The ASP will send an ASP Down to a SG when the ASP is to be removed
from the list of ASPs in all Application Servers that it is a member from the list of ASPs in the Application Server that it is a member
and no longer receive any M2UA traffic or management messages. and no longer receive any M2UA traffic or management messages.
Whether the ASP is permanently removed from an AS is a function of Whether the ASP is permanently removed from an AS is a function of
configuration management. configuration management.
The SG marks the ASP as "Down" and returns an ASP Down Ack message to The SG marks the ASP as "Down" and returns an ASP Down Ack message to
the ASP if one of the following events occur: the ASP if one of the following events occur:
- an ASP Down message is received from the ASP, - to acknowledge an ASP Down message received from a remote M2UA
- another ASPM message is received from the ASP and the SG has peer
locked out the ASP for management reasons. - to reply to an ASPM message from an ASP which is locked out
for management reasons.
The SG sends an ASP Down Ack message in response to a received ASP Down The SG sends an ASP Down Ack message in response to a received ASP Down
message from the ASP even if the ASP is already marked as "Down" at message from the ASP even if the ASP is already marked as "Down" at
the SG. the SG.
At the ASP, the ASP Down Ack message received is not acknowledged. At the ASP, the ASP Down Ack message received is not acknowledged.
Layer Management is informed with an M-ASP Down confirm primitive. Layer Management is informed with an M-ASP Down confirm primitive.
When the ASP sends an ASP Down it starts timer T(ack). If the ASP does When the ASP sends an ASP Down it starts timer T(ack). If the ASP does
not receive a response to an ASP Down within T(ack), the ASP MAY not receive a response to an ASP Down within T(ack), the ASP MAY
restart T(ack) and resend ASP Down messages until it receives an restart T(ack) and resend ASP Down messages until it receives an
ASP Down Ack message. T(ack) SHOULD be provisionable, with a default ASP Down Ack message. T(ack) SHOULD be provisionable, with a default
of 2 seconds. Alternatively, retransmission of ASP Down messages MAY of 2 seconds. Alternatively, retransmission of ASP Down messages MAY
be put under control of Layer Management. In this method, expiry of be put under control of Layer Management. In this method, expiry of
T(ack) results in a M-ASP-Down confirmation carrying a negative T(ack) results in a M-ASP-Down confirmation carrying a negative
indication. indication.
4.3.3.3 M2UA Version Control 4.3.3.3 M2UA Version Control
If a ASP Up message with an unsupported version is received, the If a ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version the receiving end responds with an Error message, indicating the version
receiving node supports. the receiving node supports.
This is useful when protocol version upgrades are being performed in a This is useful when protocol version upgrades are being performed in a
network. A node upgraded to a newer version SHOULD support the older network. A node upgraded to a newer version SHOULD support the older
versions used on other nodes it is communicating with. Because ASPs versions used on other nodes it is communicating with. Because ASPs
initiate the ASP Up procedure it is assumed that the Error message would initiate the ASP Up procedure it is assumed that the Error message
normally come from the SG. would normally come from the SG.
4.3.3.4 ASP-Active 4.3.3.4 ASP Active
Any time after the ASP has received a ASP Up Ack from the SG, the ASP Any time after the ASP has received a ASP Up Ack from the SG, the ASP
sends an ASP Active (ASPAC) to the SG indicating that the ASP is ready can send an ASP Active (ASPAC) to the SG indicating that the ASP is
to start processing traffic. In the case where an ASP is configured/- ready to start processing traffic.
registered to process the traffic for more than one Application Server
across an SCTP association, the ASPAC contains one or more Interface
Identifiers to indicate for which Application Servers the ASPAC applies.
When an ASP Active (ASPAC) message is received, the SG responds to the When an ASP Active (ASPAC) message is received, the SG responds to the
ASP with a ASPAC Ack message acknowledging that the ASPAC was received ASP with a ASPAC Ack message acknowledging that the ASPAC was received
and starts sending traffic for the associated Application Server(s) and starts sending traffic for the associated Application Server
to that ASP. Note that the SG sends an ASP Active Ack message in to that ASP. Note that the SG sends an ASP Active Ack message in
response to a received ASP Active message even if the ASP is already response to a received ASP Active message even if the ASP is already
marked as "Active" at the SG. marked as "Active" at the SG.
The ASP MUST wait for the ASP Active Ack message from the SG before The ASP MUST wait for the ASP Active Ack message from the SG before
sending any Data messages or it will risk message loss. If the SG sending any Data messages or it will risk message loss. If the SG
receives MAUP messages before an ASP Active is received, the SG SHOULD receives MAUP messages before an ASP Active is received, the SG SHOULD
discard these messages. discard these messages.
At the ASP, the ASP-Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP Active confirm primitive.
When the ASP sends an ASP Active it starts timer T(ack). If When the ASP sends an ASP Active it starts timer T(ack). If
the ASP does not receive a response to an ASP Active within T(ack), the the ASP does not receive a response to an ASP Active within T(ack), the
ASP MAY restart T(ack) and resend ASP Active messages until it ASP MAY restart T(ack) and resend ASP Active messages until it
receives an ASP Active Ack message. T(ack) SHOULD be provisionable, with receives an ASP Active Ack message. T(ack) SHOULD be provisionable, with
a default of 2 seconds. Alternatively, retransmission of ASP Active a default of 2 seconds. Alternatively, retransmission of ASP Active
messages may be put under control of Layer Management. In this method, messages may be put under control of Layer Management. In this method,
expiry of T(ack) results in a M-ASP-Active confirmation carrying a expiry of T(ack) results in a M-ASP-Active confirmation carrying a
negative indication. negative indication.
There is one mode of Application Server traffic handling in the SG There are three modes of Application Server traffic handling in the SG
M2UA - Over-ride. The Type parameter in the ASPAC messge indicates the M2UA - Over-ride, Load-share and Broadcast. The Traffic Mode Type
mode used in a particular Application Server. If the SG determines that parameter in the ASPAC messge indicates the mode used in a particular
the mode indicates in an ASPAC is incompatible with the traffic handling Application Server. If the SG determines that the mode indicates in
mode currently used in the AS, the SG responds with an Error message an ASPAC is incompatible with the traffic handling mode currently used
indicating Unsupported Traffic Handling Mode. in the AS, the SG responds with an Error message indicating Unsupported
Traffic Handling Mode.
For Over-ride mode AS, the reception of an ASPAC message at an SG causes For Over-ride mode AS, the reception of an ASPAC message at an SG causes
the redirection of all traffic for the AS to the ASP that sent the ASPAC. the redirection of all traffic for the AS to the ASP that sent the ASPAC.
The SG responds to the ASPAC with an ASP-Active Ack message to the ASP. The SG responds to the ASPAC with an ASP Active Ack message to the ASP.
Any previously active ASP in the AS is now considered Inactive and will Any previously active ASP in the AS is now considered Inactive and will
no longer receive traffic from the SG within the AS. The SG sends a no longer receive traffic from the SG within the AS. The SG sends a
Notify (Alternate ASP-Active) to the previously active ASP in the AS, Notify (Alternate ASP-Active) to the previously active ASP in the AS,
after stopping all traffic to that ASP. after stopping all traffic to that ASP.
In the case of a Load-share mode AS, reception of an ASPAC message at
an SG causes the redirection of some traffic to the ASP sending the
ASPAC. The algorithm at the SG for load-sharing traffic within an AS
to all the active ASPs is implementation dependent. The algorithm
could, for example be round-robin or based on information in the Data
message (e.g., such as the SLS in the Routing Label).
In the case of a Broadcast mode AS, reception of an ASPAC message at
an SG causes the traffic to be sent to the ASP sending the ASPAC and
the same traffic continues to be sent to the other Active ASP(s).
4.3.3.5 ASP Inactive 4.3.3.5 ASP Inactive
When an ASP wishes to withdraw from receiving traffic within an AS, When an ASP wishes to withdraw from receiving traffic within an AS,
the ASP sends an ASP Inactive (ASPIA) to the SG. In the case where the ASP sends an ASP Inactive (ASPIA) to the SG.
an ASP is configured/registered to process the traffic for more than
one Application Server across an SCTP association, the ASPIA contains
one or more Interface Ids to indicate for which Application Servers
the ASPIA applies.
There is one mode of Application Server traffic handling in the SG There are three modes of Application Server traffic handling in the SG
M2UA when withdrawing an ASP from service - Over-ride. The Type M2UA when withdrawing an ASP from service - Over-ride, Load-share and
parameter in the ASPIA messge indicates the mode used in a particular Broadcast. The Traffic Mode Type parameter in the ASPIA messge indicates
Application Server. If the SG determines that the mode indicates in an the mode used in a particular Application Server. If the SG determines
ASPAC is incompatible with the traffic handling mode currently used in that the mode indicates in an ASPAC is incompatible with the traffic
the AS, the SG responds with an Error message indicating Unsupported handling mode currently used in the AS, the SG responds with an Error
Traffic Handling Mode. message indicating Unsupported Traffic Handling Mode.
In the case of an Over-ride mode AS, where normally another ASP has In the case of an Over-ride mode AS, where normally another ASP has
already taken over the traffic within the AS with an Over-ride ASPAC, already taken over the traffic within the AS with an Over-ride ASPAC,
the ASP which sends the ASPIA is already considered by the SG to be the ASP which sends the ASPIA is already considered by the SG to be
"Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is "Inactive" (i.e., in the "Inactive" state). An ASPIA Ack message is
sent to the ASP, after ensuring that all traffic is stopped to the ASP. sent to the ASP, after ensuring that all traffic is stopped to the ASP.
In the case of a Load-share mode AS, the SG moves the ASP to the
"Inactive" state and the AS traffic is re-allocated across the
remaining "active" ASPs per the load-sharing algorithm currently used
within the AS. A NTFY(Insufficient ASP resources active in AS) may be
sent to all inactive ASPs, if required. An ASPIA Ack message is sent
to the ASP after all traffic is halted and Layer Management is informed
with an ASP-INACTIVE indication primitive.
In the case of a Broadcast mode AS, the SG moves the ASP to the
"Inactive" state and stops sending the AS traffic to the ASP. The
SG continues to send the AS traffic to the remaining "active" ASPs.
A NTFY(Insufficient ASP resources active in AS) may be sent to all
inactive ASPs, if required. An ASPIA Ack message is sent to the ASP
after all traffic is halted and Layer Management is informed with an
ASP-INACTIVE indication primitive.
When the ASP sends an ASP Inactive it starts timer T(ack). If the ASP When the ASP sends an ASP Inactive it starts timer T(ack). If the ASP
does not receive a response to an ASP Inactive within T(ack), the ASP does not receive a response to an ASP Inactive within T(ack), the ASP
MAY restart T(ack) and resend ASP Inactive messages until it receives MAY restart T(ack) and resend ASP Inactive messages until it receives
an ASP Inactive Ack message. T(ack) SHOULD be provisionable, with a an ASP Inactive Ack message. T(ack) SHOULD be provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Inactive default of 2 seconds. Alternatively, retransmission of ASP Inactive
messages may be put under control of Layer Management. In this method, messages may be put under control of Layer Management. In this method,
expiry of T(ack) results in a M-ASP-Inactive confirmation carrying a expiry of T(ack) results in a M-ASP-Inactive confirmation carrying a
negative indication. negative indication.
If no other ASPs are Active in the Application Server, the SG either If no other ASPs are Active in the Application Server, the SG either
discards all incoming messages for the AS or starts buffering the discards all incoming messages for the AS or starts buffering the
incoming messages for T(r) seconds, after which messages will be incoming messages for T(r) seconds, after which messages will be
discarded. T(r) is configurable by the network operator. If the SG discarded. T(r) is configurable by the network operator. If the SG
receives an ASPAC from an ASP in the AS before expiry of T(r), the receives an ASPAC from an ASP in the AS before expiry of T(r), the
buffered traffic is directed to the ASP and the timer is cancelled. buffered traffic is directed to the ASP and the timer is cancelled.
4.3.3.6 Notify 4.3.3.6 Notify
A Notify message reflecting a change in the AS state is sent to all A Notify message reflecting a change in the AS state is sent to all
ASPs in the AS, except those in the "Down" state, with appropriate ASP(s) in the AS, except those in the "Down" state, with appropriate
Status Identification. Status Information.
In the case where a Notify (AS-Pending) message is sent by an SG In the case where a Notify (AS-Pending) message is sent by an SG
that now has no ASPs active to service the traffic, the Notify does that now has no ASP(s) active to service the traffic, the Notify does
not explicitly force the ASP(s) receiving the message to become not explicitly force the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) action is active. The ASP remain in control of what (and when) action is
taken. taken.
In addition, the Notify message will be sent to all ASP(s) in the
AS, except those in the "Down" state, when an ASP fails with the
ASP Identifier of the failed ASP.
5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 5.0 Examples of MTP2 User Adaptation (M2UA) Procedures
5.1 Establishment of associations between SG and MGC examples 5.1 Establishment of associations between SG and MGC examples
5.1.1 Single ASP in an Application Server (1+0 sparing) 5.1.1 Single ASP in an Application Server (1+0 sparing)
This scenario shows the example M2UA message flows for the establishment This scenario shows the example M2UA message flows for the establishment
of traffic between an SG and an ASP, where only one ASP is configured of traffic between an SG and an ASP, where only one ASP is configured
within an AS (no backup). It is assumed that the SCTP association is within an AS (no backup). It is assumed that the SCTP association is
already set-up. already set-up.
skipping to change at page 31, line 79 skipping to change at page 31, line 79
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm--> -Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = -1) (seq_num = -1)
An example of a message flow for a request to drop messages (clear An example of a message flow for a request to drop messages (clear
retransmission buffers) is shown below. retransmission buffers) is shown below.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG ASP ASP
<-Clr RTB Req-|<--Rtrv Req (ACTION_DROP_MSGS)--|<--Clr RTB Req--- <-Clr TB/RTB Req-|<-Rtrv Req (ACTION_DROP_MSGS)-|<--Clr TB/RTB Req---
-Clr RTB Ind->|---Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr RTB Ind--> -Clr TB/RTB Ind->|-Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr TB/RTB Ind-->
5.3.7 Flush and Continue 5.3.7 Flush and Continue
The following message flow shows a request to flush buffers. The following message flow shows a request to flush buffers.
MTP2 M2UA M2UA MTP3 MTP2 M2UA M2UA MTP3
SG SG ASP ASP SG SG ASP ASP
<--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req-- <--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req--
skipping to change at page 31, line 149 skipping to change at page 31, line 149
MTP2 M2UA M2UA MGMT MTP2 M2UA M2UA MGMT
SG SG ASP ASP SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit------- |<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->| |-----State Cfm (STATUS_AUDIT)--->|
MTP3 MTP3
ASP ASP
|-----------Establish Ind-------->|---In Serv Ind --> |-----------Establish Cfm-------->|---In Serv Ind-->
|----------Congestion Ind-------->|---Cong Ind -----> |----------Congestion Ind-------->|---Cong Ind ----->
Below is an example in which the SS7 link is in-service, but in Remote Below is an example in which the SS7 link is in-service, but in Remote
Processor Outage. Processor Outage.
MTP2 M2UA M2UA MGMT MTP2 M2UA M2UA MGMT
SG SG ASP ASP SG SG ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit------- |<----State Req (STATUS_AUDIT)----|<----Audit-------
|-----State Cfm (STATUS_AUDIT)--->| |-----State Cfm (STATUS_AUDIT)--->|
MTP3 MTP3
ASP ASP
|-----------Establish Ind-------->|---In Serv Ind --> |-----------Establish Ind-------->|---In Serv Ind -->
|---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter ---> |---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter --->
6.0 Security 6.0 Timer Values
M2UA is designed to carry signaling messages for telephony services. As such, The recommended default values for M2UA timers are:
M2UA MUST involve the security needs of several parties: the end users
of the services; the network providers and the applications involved.
Additional requirements MAY come from local regulation. While having some
overlapping security needs, any security solution SHOULD fulfill all of the
different parties' needs.
6.1 Threats T(r) 2 seconds
T(ack) 2 seconds
7.0 Security
M2UA is designed to carry signaling messages for telephony services.
As such, M2UA MUST involve the security needs of several parties: the
end users of the services; the network providers and the applications
involved. Additional requirements MAY come from local regulation.
While having some overlapping security needs, any security solution
SHOULD fulfill all of the different parties' needs.
7.1 Threats
There is no quick fix, one-size-fits-all solution for security. As a There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, M2UA has the following security objectives: transport protocol, M2UA has the following security objectives:
* Availability of reliable and timely user data transport. * Availability of reliable and timely user data transport.
* Integrity of user data transport. * Integrity of user data transport.
* Confidentiality of user data. * Confidentiality of user data.
M2UA runs on top of SCTP. SCTP [5] provides certain transport related M2UA runs on top of SCTP. SCTP [5] provides certain transport related
security features, such as: security features, such as:
skipping to change at page 32, line 6 skipping to change at page 32, line 6
* Flooding * Flooding
* Masquerade * Masquerade
* Improper Monopolization of Services * Improper Monopolization of Services
When M2UA is running in professionally managed corporate or service When M2UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network includes provider network, it is reasonable to expect that this network includes
an appropriate security policy framework. The "Site Security Handbook" an appropriate security policy framework. The "Site Security Handbook"
[10] SHOULD be consulted for guidance. [10] SHOULD be consulted for guidance.
When the network in which M2UA runs in involves more than one party, it When the network in which M2UA runs in involves more than one party, it
MAY NOT be reasonable to expect that all parties have implemented security MAY NOT be reasonable to expect that all parties have implemented
in a sufficient manner. In such a case, it is recommended that IPSEC is security in a sufficient manner. In such a case, it is recommended that
used to ensure confidentiality of user payload. Consult [11] for more IPSEC is used to ensure confidentiality of user payload. Consult [11]
information on configuring IPSEC services. for more information on configuring IPSEC services.
6.2 Protecting Confidentiality 7.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality MAY Particularly for mobile users, the requirement for confidentiality MAY
include the masking of IP addresses and ports. In this case application include the masking of IP addresses and ports. In this case application
level encryption is not sufficient; IPSEC ESP SHOULD be used instead. level encryption is not sufficient; IPSEC ESP SHOULD be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP Regardless of which level performs the encryption, the IPSEC ISAKMP
service SHOULD be used for key management. service SHOULD be used for key management.
7.0 IANA Considerations 8.0 IANA Considerations
7.1 SCTP Payload Protocol Identifier 8.1 SCTP Payload Protocol Identifier
A request will be made to IANA to assign an M2UA value for the Payload A request will be made to IANA to assign an M2UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Protocol Identifier will be registered: Payload Protocol Identifier will be registered:
M2UA 0x10 M2UA 0x10
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, The SCTP Payload Protocol Identifier is included in each SCTP Data chunk,
to indicate which protocol the SCTP is carrying. This Payload Protocol to indicate which protocol the SCTP is carrying. This Payload Protocol
Identifier is not directly used by SCTP but MAY be used by certain network Identifier is not directly used by SCTP but MAY be used by certain
entities to identify the type of information being carried in a Data chunk. network entities to identify the type of information being carried in a
Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a way The User Adaptation peer MAY use the Payload Protocol Identifier as a
of determining additional information about the data being presented to it way of determining additional information about the data being presented
by SCTP. to it by SCTP.
7.2 M2UA Protocol Extensions 8.2 M2UA Protocol Extensions
This protocol may also be extended through IANA in three ways: This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes, -- through definition of additional message classes,
-- through definition of additional message types, and -- through definition of additional message types, and
-- through definition of additional message parameters. -- through definition of additional message parameters.
The definition and use of new message classes, types and parameters is The definition and use of new message classes, types and parameters is
an integral part of SIGTRAN adaptation layers. Thus, these extensions an integral part of SIGTRAN adaptation layers. Thus, these extensions
are assigned by IANA through an IETF Consensus action as defined in are assigned by IANA through an IETF Consensus action as defined in
[RFC2434]. [RFC2434].
The proposed extension must in no way adversely affect the general The proposed extension must in no way adversely affect the general
working of the protocol. working of the protocol.
7.2.1 IETF Defined Message Classes 8.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following The documentation for a new message class MUST include the following
information: information:
(a) A long and short name for the message class. (a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class. (b) A detailed description of the purpose of the message class.
7.2.2 IETF Defined Message Types 8.2.2 IETF Defined Message Types
Documentation of the message type MUST contain the following information: Documentation of the message type MUST contain the following information:
(a) A long and short name for the new message type. (a) A long and short name for the new message type.
(b) A detailed description of the structure of the message. (b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each field (c) A detailed definition and description of intended use of each field
within the message. within the message.
(d) A detailed procedural description of the use of the new message type (d) A detailed procedural description of the use of the new message type
within the operation of the protocol. within the operation of the protocol.
(e) A detailed description of error conditions when receiving this message (e) A detailed description of error conditions when receiving this message
type. type.
When an implementation receives a message type which it does not support, When an implementation receives a message type which it does not support,
it MUST respond with an Error (ERR) message with an Error Code of it MUST respond with an Error (ERR) message with an Error Code of
Unsupported Message Type. Unsupported Message Type.
7.2.3 IETF-defined TLV Parameter Extension 8.2.3 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following Documentation of the message parameter MUST contain the following
information: information:
(a) Name of the parameter type. (a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field. This (b) Detailed description of the structure of the parameter field. This
structure MUST conform to the general type-length-value format structure MUST conform to the general type-length-value format
described in Section 3.1.5. described in Section 3.1.5.
(c) Detailed definition of each component of the parameter value. (c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type, (d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within the multiple instances of this parameter type may be found within the
same message type. same message type.
8.0 Acknowledgements 9.0 Acknowledgements
The authors would like to thank John Loughney, Neil Olson, Michael The authors would like to thank John Loughney, Neil Olson, Michael
Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz
Prantner, Barry Nagelberg, Naoto Makinae and Brian Bidulock for their Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald and Mark
valuable comments and suggestions. Kobine for their valuable comments and suggestions.
9.0 References 10.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)' System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) -
Message Transfer Part (MTP)' Message Transfer Part (MTP)'
[3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[4] Bellcore GR-246-CORE 'Bell Communications Research Specification [4] Bellcore GR-246-CORE 'Bell Communications Research Specification
skipping to change at page 33, line 37 skipping to change at page 33, line 37
functions and messages using the services of ITU-T functions and messages using the services of ITU-T
Recommendation Q.2140', August 1995 Recommendation Q.2140', August 1995
[9] ITU-T Recommendation Q.751.1, 'Network Element Management Information [9] ITU-T Recommendation Q.751.1, 'Network Element Management Information
Model for the Messsage Transfer Part', October 1995 Model for the Messsage Transfer Part', October 1995
[10] Site Security Handbook, RFC 2196, September 1997 [10] Site Security Handbook, RFC 2196, September 1997
[11] Security Architecture for the Internet Protocol, RFC 2401 [11] Security Architecture for the Internet Protocol, RFC 2401
[12] draft-stewart-srwnd-sctp-sigtran-01.txt, SCTP Stream Based Flow [12] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip-
Control, November 2000 sctp-00.txt, May 7, 2001
10.0 Issues To Be Addressed
1. SCTP congestion (what does M2UA on SG and MGC do)
10.0 Author's Addresses 11.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Ram Dantu, Ph.D. Tel +1-469-255-0716 Ram Dantu, Ph.D. Tel +1-469-255-0716
Cisco Systems EMail rdantu@cisco.com Cisco Systems EMail rdantu@cisco.com
17919 Waterview 17919 Waterview
skipping to change at line 2996 skipping to change at line 3143
c/o #424, 4701 Preston Park Blvd. c/o #424, 4701 Preston Park Blvd.
Dallas, TX 75093 Dallas, TX 75093
USA USA
Jacob Heitz Tek +1-510-747-2917 Jacob Heitz Tek +1-510-747-2917
Lucent Technologies Email: jheitz@lucent.com Lucent Technologies Email: jheitz@lucent.com
1701 Harbor Bay Parkway 1701 Harbor Bay Parkway
Alameda, CA, 94502 Alameda, CA, 94502
USA USA
This Internet Draft expires April 2001. This Internet Draft expires December 2001.
 End of changes. 

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