draft-ietf-sigtran-m2ua-12.txt   draft-ietf-sigtran-m2ua-13.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
NetRake NetRake
Greg Sidebottom Greg Sidebottom
gregside consulting gregside consulting
Tom George Tom George
Alcatel Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Jacob Heitz Jacob Heitz
Lucent Lucent
Expires in May 2002 Dec 2001 Expires in June 2002 Jan 2002
Signaling System 7 (SS7) Message Transfer Part (MTP) 2 - Signaling System 7 (SS7) Message Transfer Part (MTP) 2 -
User Adaptation Layer User Adaptation Layer
<draft-ietf-sigtran-m2ua-12.txt> <draft-ietf-sigtran-m2ua-13.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 3, line 9 skipping to change at page 3, line 9
8.1 SCTP Payload Protocol Identifier.......................72 8.1 SCTP Payload Protocol Identifier.......................72
8.2 IUA Protocol Extensions................................72 8.2 IUA Protocol Extensions................................72
9. Acknowledgements.........................................74 9. Acknowledgements.........................................74
10. References...............................................74 10. References...............................................74
11. Author's Addresses.......................................75 11. Author's Addresses.......................................75
1. Introduction 1. Introduction
This draft defines a protocol for the backhauling of SS7 [1] MTP2 User This draft defines a protocol for the backhauling of SS7 [1] MTP2 User
[2] [3] (i.e. MTP3) signalling messages over IP using the Stream Control [2] [3] (i.e. MTP3) signalling messages over IP using the Stream Control
Transmission Protocol (SCTP) [5]. This protocol would be used between Transmission Protocol (SCTP) [6]. This protocol would be used between
a Signalling Gateway (SG) and Media Gateway Controller (MGC). a Signalling Gateway (SG) and Media Gateway Controller (MGC).
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling protocol There is a need for Switched Circuit Network (SCN) signalling protocol
delivery from an Signalling Gateway (SG) to a Media Gateway delivery from an Signalling Gateway (SG) to a Media Gateway
Controller (MGC) [6]. The delivery mechanism addresses the following Controller (MGC) [7]. The delivery mechanism addresses the following
objectives: objectives:
* 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 SCTP active associations between the SG and * Support for management of SCTP active associations between the SG and
MGC MGC
The SG will terminate up to MTP Level 2 and the MGC will terminate The SG will terminate up to MTP Level 2 and the MGC will terminate
MTP Level 3 and above. In other words, the SG will transport MTP MTP Level 3 and above. In other words, the SG will transport MTP
skipping to change at page 5, line 8 skipping to change at page 5, line 8
implementation [2]. implementation [2].
Stream - A stream refers to an SCTP stream; a unidirectional logical Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service. except for those submitted to the unordered delivery service.
1.3 M2UA Overview 1.3 M2UA Overview
The framework architecture that has been defined for SCN signalling The framework architecture that has been defined for SCN signalling
transport over IP [6] uses two components: a signalling common transport over IP [7] uses two components: a signalling common
transport protocol and an adaptation module to support the services transport protocol and an adaptation module to support the services
expected by a particular SCN signalling protocol from its underlying expected by a particular SCN signalling protocol from its 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 [6] as the underlying
reliable signalling common transport protocol. reliable signalling common transport protocol.
In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling
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 signalling messages to and to provide reliable transport of the MTP3-User signalling messages to and
from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP).
The SG then provides a interworking of transport functions The SG then provides a interworking of transport functions
with the IP transport, in order to transfer the MTP2-User signalling with the IP transport, in order to transfer the MTP2-User signalling
messages to and from an Application Server Process where the peer MTP2- messages to and from an Application Server Process where the peer MTP2-
skipping to change at page 5, line 61 skipping to change at page 5, line 61
|MTP | |MTP |M2UA| |M2UA| |MTP | |MTP |M2UA| |M2UA|
| | | +----+ +----+ | | | +----+ +----+
|L2 | |L2 |SCTP| |SCTP| |L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+ |L1 | |L1 +----+ +----+
| | | |IP | |IP | | | | |IP | |IP |
+----+ +---------+ +----+ +----+ +---------+ +----+
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
SEP - SS7 Signalling Endpoint SEP - SS7 Signalling Endpoint
IP - Internet Protocol IP - Internet Protocol
SCTP - Stream Control Transmission Protocol (Reference [5]) SCTP - Stream Control Transmission Protocol (Reference [6])
Figure 1 M2UA in the SG to MGC Application Figure 1 M2UA in the SG to MGC Application
Note: STPs MAY be present in the SS7 path between the SEP and the SG. Note: STPs MAY be present in the SS7 path between the SEP and the SG.
It is recommended that the M2UA use the services of the Stream It is recommended that the M2UA use the services of the Stream
Control Transmission Protocol (SCTP) as the underlying reliable Control Transmission Protocol (SCTP) as the underlying reliable
common signalling transport protocol. The use of SCTP provides common signalling transport protocol. The use of SCTP provides
the following features: the following features:
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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.
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 need to 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 [8].
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
The M2UA layer needs to provide some messages that will facilitate The M2UA layer needs to provide some messages that will facilitate
communication between Layer Management modules on the SG and MGC. communication between Layer Management modules on the SG and MGC.
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:
skipping to change at page 9, line 38 skipping to change at page 9, line 38
1.5.1 Mapping 1.5.1 Mapping
The M2UA layer MUST maintain a map of a Interface ID to a physical The M2UA layer MUST maintain a map of a Interface ID to a physical
interface on the Signalling Gateway. A physical interface would be a interface on the Signalling Gateway. A physical interface would be a
V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer
MUST also maintain a map of Interface Identifier to SCTP association MUST also maintain a map of Interface Identifier to SCTP association
and to the related stream within the association. and to the related stream within the association.
The SGP maps an Interface Identifier to an SCTP association/stream The SGP maps an Interface Identifier to an SCTP association/stream
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 SGP MUST maintain the states of AS/ASP ASP to another. Therefore, the SGP 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.
Note that only one SGP SHOULD provide Signalling Link Terminal Note that only one SGP SHOULD provide Signalling Link Terminal
services to an SS7 link. Therefore, within an SG, an Application services to an SS7 link. Therefore, within an SG, an Application
Server MUST be active for only one SGP at any given point in time. Server SHOULD be active for only one SGP at any given point in time.
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 an SGP is shown below: Interface Identifier, AS and ASP in an SGP is shown below:
/-------------------------------------------------+ /-------------------------------------------------+
/ /----------------------------------------------|--+ / /----------------------------------------------|--+
/ / v | / / v |
/ / +----+ act+-----+ +-------+ -+--+|-+- / / +----+ act+-----+ +-------+ -+--+|-+-
SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+- / +----+ | +----+ | +-----+ +-------+ -+--+--+-
skipping to change at page 11, line 58 skipping to change at page 11, line 58
DATA DATA
ESTABLISH ESTABLISH
RELEASE RELEASE
STATE STATE
DATA RETRIEVAL DATA RETRIEVAL
DATA RETRIEVAL COMPLETE DATA RETRIEVAL COMPLETE
1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP
The upper layer and layer management primitives provided by SCTP are The upper layer and layer management primitives provided by SCTP are
provided in Reference [5] Section 9. provided in Reference [6] Section 9.
1.6.4 Definition of Layer Management / M2UA Boundary 1.6.4 Definition of Layer Management / M2UA Boundary
M-SCTP_ESTABLISH request M-SCTP_ESTABLISH request
Direction: LM -> M2UA Direction: LM -> M2UA
Purpose: LM requests ASP to establish an SCTP association with an Purpose: LM requests ASP to establish an SCTP association with an
SGP. SGP.
M-SCTP_ESTABLISH confirm M-SCTP_ESTABLISH confirm
Direction: M2UA -> LM Direction: M2UA -> LM
skipping to change at page 19, line 55 skipping to change at page 19, line 55
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Correlation Id parameter of the Data message and the Data Ack The Correlation Id parameter of the Data message and the Data Ack
message provide a mechanism, for those SG implementations capable for message provide a mechanism, for those SG implementations capable for
taking advantage of them, to obtain an acknowledgement that the MSU taking advantage of them, to obtain an acknowledgement that the MSU
has been transferred to the M2UA peer before acknowleding the MSU to has been transferred to the M2UA peer before acknowleding the MSU to
the SS7 peer, removing the risk of losing messages due to association the SS7 peer, removing the risk of losing messages due to association
failure or SCTP congestion. failure or SCTP congestion.
The Data Ack message MUST be sent if a Correlation Id parameter is The Data Ack message MUST be sent if a Correlation Id parameter is
received from the peer. Otherwise the Data Ack message SHOULD NOT be received from the peer. Otherwise, the Data Ack message MUST NOT be
sent. sent.
If the Data Acknowledge is not sent for Correlation Id(s) or is sent If the Data Acknowledge is not sent for Correlation Id(s) or is sent
with Invalid Correlation Id(s), the SS7 link will eventually fail with Invalid Correlation Id(s), the SS7 link will eventually fail
dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs. dueto lack of MTP Level 2 acknowledgements of the SS7 peer's MSUs.
3.3.1.3 Establish (Request, Confirmation) 3.3.1.3 Establish (Request, Confirmation)
The Establish Request message is used to establish the SS7 link or to The Establish Request message is used to establish the SS7 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
skipping to change at page 21, line 42 skipping to change at page 21, line 42
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 (0x302) | Length = 8 | | Tag (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 of the State field SHOULD reflect the value received in the State
Request message. Request 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
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
skipping to change at page 22, line 37 skipping to change at page 22, line 37
EVENT_LPO_ENTER 0x3 Link entered processor outage EVENT_LPO_ENTER 0x3 Link entered processor outage
EVENT_LPO_EXIT 0x4 Link exited processor outage EVENT_LPO_EXIT 0x4 Link exited processor outage
3.3.1.8 Congestion Indication 3.3.1.8 Congestion Indication
The Congestion Indication message can be sent from a Signalling Gateway The Congestion Indication message can be sent from a Signalling Gateway
Process to an ASP to indicate the congestion status and discard status Process to an ASP to indicate the congestion status and discard status
of a SS7 link. When the MSU buffer fill increases above an Onset of a SS7 link. When the MSU buffer fill increases above an Onset
threshold or decreases below an Abatement threshold or crosses a Discard threshold or decreases below an Abatement threshold or crosses a Discard
threshold in either direction, the SGP SHALL send a congestion indication threshold in either direction, the SGP SHALL send a congestion indication
message. message when it supports SS7 MTP2 variants that support multiple congestion
levels.
The SGP SHALL send the message only when there is actually a change The SGP 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 SGP SHALL use an implementation dependent algorithm to limit the the SGP 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). [13] 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 (0x304) | Length = 8 | | Tag (0x304) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 28 skipping to change at page 23, line 28
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
For SS7 networks that do not support multiple levels of congestion, only For SS7 networks that do not support multiple levels of congestion, only
the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that the LEVEL_NONE and LEVEL_3 values will be used. For SS7 networks that
support multiple levels of congestion, it is possible for all values to support multiple levels of congestion, it is possible for all values to
be used. Refer to [2], [3] and [9] for more details on the Congestion be used. Refer to [2], [3] and [10] for more details on the Congestion
and Discard Status of SS7 signalling links. and Discard Status of SS7 signalling links.
3.3.1.9 Retrieval Request 3.3.1.9 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
transmit and retransmit queues or to flush PDUs from the retransmit transmit and retransmit queues or to flush PDUs from the retransmit
queue. Examples of the use of Retrieval Request for SS7 Link queue. Examples of the use of Retrieval Request for SS7 Link
Changeover are provided in Section 5.3.6. Changeover are provided in Section 5.3.6.
skipping to change at page 25, line 50 skipping to change at page 25, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The M2UA implementation MAY consider the use of the bundling feature The M2UA implementation MAY consider the use of the bundling feature
of SCTP for Retrieval Indication messages. of SCTP for Retrieval Indication messages.
3.3.1.12 Retrieval Complete Indication 3.3.1.12 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 the MTP2 Retrieval Indication message except that it also indicates
that retrieval is complete. In addition, it MAY contain a PDU (which that retrieval is complete. In addition, it MAY contain a PDU (which
must be the last PDU) from the transmit or retransmit queue. MUST be 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.
skipping to change at page 26, line 36 skipping to change at page 26, line 36
/ \ / \
\ INFO String* / \ INFO String* /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter would contain a unique value The optional ASP Identifier parameter would contain a unique value
that is locally significant among the ASPs that support an AS. The that is locally significant among the ASPs that support an AS. The
SGP should save the ASP Identifier to be used, if necessary, with the SGP should save the ASP Identifier to be used, if necessary, with the
Notify message (see Section 3.3.3.2). 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 UTF-8 [5]
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 The ASP Up Ack message is used to acknowledge an ASP Up message
received from a remote M2UA peer. received from a remote M2UA peer.
skipping to change at page 38, line 47 skipping to change at page 38, line 47
Not Used in M2UA 0xa Not Used in M2UA 0xa
Not Used in M2UA 0xb Not Used in M2UA 0xb
Not Used in M2UA 0xc Not Used in M2UA 0xc
Refused - Management Blocking 0xd Refused - Management Blocking 0xd
ASP Identifier Required 0xe ASP Identifier Required 0xe
Invalid ASP Identifier 0xf Invalid ASP Identifier 0xf
ASP Active for Interface Identifier(s) 0x10 ASP Active for Interface Identifier(s) 0x10
Invalid Parameter Value 0x11 Invalid Parameter Value 0x11
Parameter Field Error 0x12 Parameter Field Error 0x12
Unexpected Parameter 0x13 Unexpected Parameter 0x13
Not Used in M2UA 0x14
Not Used in M2UA 0x15
Missing Parameter 0x16
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 SGP if The "Invalid Interface Identifier" error would be sent by a SGP if
an ASP sends a message (i.e. an ASP Active message) with an invalid an ASP sends a message (i.e. an ASP Active message) with an invalid
(unconfigured) Interface Identifier value. One of the optional (unconfigured) Interface Identifier value. One of the optional
skipping to change at page 39, line 37 skipping to change at page 39, line 37
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.
The "Refused - Management Blocking" error is sent when an ASP Up or The "Refused - Management Blocking" error is sent when an ASP Up or
ASP Active message is received and the request is refused for ASP Active message is received and the request is refused for
management reasons (e.g., management lock-out"). management reasons (e.g., management lock-out").
The "ASP Identifier Required" is sent by a SGP in response The "ASP Identifier Required" is sent by a SGP in response
to an ASPUP message which does not contain an ASP Identifier to an ASPUP message which does not contain an ASP Identifier
parameter when the SGP requires one. The ASP should resend the parameter when the SGP requires one. The ASP SHOULD resend the
ASPUP message with a ASP Identifier. ASPUP message with an ASP Identifier.
The "Invalid ASP Identifier" is send by a SGP in response to an The "Invalid ASP Identifier" is send by a SGP in response to an
ASPUP message with an invalid (i.e. non-unique) ASP Identifier. ASPUP message with an invalid (i.e. non-unique) ASP Identifier.
The "ASP Currently Active for Interface Identifier(s)" error is The "ASP Currently Active for Interface Identifier(s)" error is
sent by a SGP when a Deregistration request is received from an ASP sent by a SGP when a Deregistration request is received from an ASP
that is active for Interface Identifier(s) specified in the that is active for Interface Identifier(s) specified in the
Deregistration request. One of the optional Interface Identifier Deregistration request. One of the optional Interface Identifier
parameters (Integer-based, text-based or integer range) MAY be used parameters (Integer-based, text-based or integer range) MAY be used
with this error code to identify the Interface Identifier(s). with this error code to identify the Interface Identifier(s).
skipping to change at page 39, line 60 skipping to change at page 39, line 60
The "Invalid Parameter Value " error is sent if a message is received The "Invalid Parameter Value " error is sent if a message is received
with an invalid parameter value (e.g., a State Request with an with an invalid parameter value (e.g., a State Request with an
an undefined State). an undefined State).
The "Parameter Field Error" would be sent if a message with a The "Parameter Field Error" would be sent if a message with a
parameter that has a wrong length field. parameter that has a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter. an invalid parameter.
The "Missing Parameter" error would be sent if a mandatory parameter
were not included in a message.
The optional Diagnostic information can be any information germane to The optional Diagnostic information can be any information germane 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 SHOULD be the first 40 bytes of the offending Diagnostic information SHOULD be the first 40 bytes of the offending
message. message.
3.3.3.2 Notify (NTFY) 3.3.3.2 Notify (NTFY)
The Notify message is used to provide an autonomous indication of M2UA The Notify message is used to provide an autonomous indication of M2UA
skipping to change at page 41, line 50 skipping to change at page 41, line 50
Value Description Value Description
0x1 Application Server state change (AS_State_Change) 0x1 Application Server state change (AS_State_Change)
0x2 Other 0x2 Other
The Status Information parameter contains more detailed information The Status Information parameter contains more detailed information
for the notification, based on the value of the Status Type. If the for the notification, based on the value of the Status Type. If the
Status Type is AS_State_Change the following Status Information values Status Type is AS_State_Change the following Status Information values
are used: are used:
Value Description Value Description
1 Application Server Down (AS_Down) 1 reserved
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 SGP to an ASP upon a change in These notifications are sent from an SGP to an ASP upon a change in
status of a particular Application Server. The value reflects the status of a particular Application Server. The value reflects the
new state of the Application Server. The Interface Identifiers of new state of the Application Server. The Interface Identifiers of
the AS MAY be placed in the message if desired. the AS MAY be placed in the message if desired.
If the Status Type is Other, then the following Status Information If the Status Type is Other, then the following Status Information
skipping to change at page 43, line 53 skipping to change at page 43, line 53
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signalling Data Link Identifier | | Signalling Data Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-LK-Identifier: 32-bit integer Local-LK-Identifier: 32-bit integer
The mandatory Local-LK-Identifier field is used to uniquely The mandatory Local-LK-Identifier field is used to uniquely
(between ASP and SGP) identify the registration request. The (between ASP and SGP) identify the registration request. The
Identifier value is assigned by the ASP, and is used to correlate Identifier value is assigned by the ASP, and is used to correlate
the response in a REG RSP message with the original registration the response in a REG RSP message with the original registration
request. The Identifier value must remain unique until the REG request. The Identifier value MUST remain unique until the REG
RSP is received. RSP is received.
The format of the Local-LK-Identifier field is as follows: The format of the Local-LK-Identifier field 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 = 0x030a | Length = 8 | | Tag = 0x030a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-LK-Identifier value | | Local-LK-Identifier value |
skipping to change at page 51, line 38 skipping to change at page 51, line 38
in the AS (e.g., ASP Active message indicating "Override"); in the AS (e.g., ASP Active message indicating "Override");
* Reception of indications from the SCTP layer; or * Reception of indications from the SCTP layer; or
* Local Management intervention. * Local Management intervention.
The ASP state transition diagram is shown in Figure 5. The possible The ASP state transition diagram is shown in Figure 5. The possible
states of an ASP are: states of an ASP are:
ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the
related SCTP association is down. Initially all ASPs will be in this related SCTP association is down. Initially all ASPs will be in this
state. An ASP in this state SHOULD NOT be sent any M2UA messages, with state. An ASP in this state SHOULD NOT be sent any M2UA messages, with
the exception of Heartbeat messages. the exception of Heartbeat, ASP Down Ack and Error 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 MAY be sent any non-MAUP M2UA messages. In this state the ASP MAY 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 (for a particular Interface Identifier application traffic is active (for a particular Interface Identifier
or set of Interface Identifiers). or set of Interface Identifiers).
Figure 5: ASP State Transition Diagram Figure 5: ASP State Transition Diagram
skipping to change at page 54, line 45 skipping to change at page 54, line 45
4.3.3 M2UA Management Procedures for Primitives 4.3.3 M2UA Management Procedures for Primitives
Before the establishment of an SCTP association the ASP state at both Before the establishment of an SCTP association the ASP state at both
the SGP and ASP is assumed to be in the state ASP-DOWN. the SGP and ASP is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (see Section 4.2.1) and Once the SCTP association is established (see Section 4.2.1) and
assuming that the local M2UA-User is ready, the local M2UA ASP assuming that the local M2UA-User is ready, the local M2UA ASP
Maintenance (ASPM) function will initiate the relevant procedures, Maintenance (ASPM) function will initiate the relevant procedures,
using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
the ASP state to the SGP (see Section 4.4.3). the ASP state to the SGP (see Section 4.3.4).
If the M2UA layer subsequently receives an SCTP-COMMUNICATION_DOWN If the M2UA layer subsequently receives an SCTP-COMMUNICATION_DOWN
or SCTP-RESTART indication primitive from the underlying SCTP layer, or SCTP-RESTART indication primitive from the underlying SCTP layer,
it will inform the Layer Management by invoking the M-SCTP_STATUS it will inform the Layer Management by invoking the M-SCTP_STATUS
indication primitive. The state of the ASP will be moved to ASP-DOWN. indication primitive. The state of the ASP will be moved to ASP-DOWN.
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re- In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-
establish the SCTP association. This MAY be done by the M2UA layer establish the SCTP association. This MAY be done by the M2UA layer
automatically, or Layer Management MAY re-establish using the automatically, or Layer Management MAY re-establish using the
M-SCTP_ESTABLISH request primitive. M-SCTP_ESTABLISH request primitive.
skipping to change at page 55, line 42 skipping to change at page 55, line 42
should save the ASP Identifier for that ASP. The SGP MUST send an should save the ASP Identifier for that ASP. The SGP MUST send an
ASP Up Ack message in response to a received ASP Up message even if ASP Up Ack message in response to a received ASP Up message even if
the ASP is already marked as ASP-INACTIVE at the SGP. the ASP is already marked as ASP-INACTIVE at the SGP.
If for any local reason (e.g., management lock-out) the SGP cannot If for any local reason (e.g., management lock-out) the SGP cannot
respond with an ASP Up Ack message, the SGP responds to an ASP Up respond with an ASP Up Ack message, the SGP responds to an ASP Up
message with an Error message with Reason "Refused - Management message with an Error message with Reason "Refused - Management
Blocking". Blocking".
At the ASP, the ASP Up Ack message received is not acknowledged. Layer At the ASP, the ASP Up Ack message received is not acknowledged. Layer
Management is informed with an M-ASP_UP confirm primitive. When an ASP Management is informed with an M-ASP_UP confirm primitive.
enters the ASP-INACTIVE state from the ASP-DOWN state towards an SGP
the M2UA MUST mark all SS7 destinations configured to be reachable via
this SGP as available.
When the ASP sends an ASP Up message it starts timer T(ack). If the When the ASP sends an ASP Up message it starts timer T(ack). If the
ASP does not receive a response to an ASP Up message within T(ack), the ASP does not receive a response to an ASP Up message within T(ack), the
ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP MAY restart T(ack) and resend ASP Up messages until it receives an
ASP Up Ack message. T(ack) is provisionable, with a default of 2 ASP Up Ack message. T(ack) is provisionable, with a default of 2
seconds. Alternatively, retransmission of ASP Up messages MAY be put seconds. Alternatively, retransmission of ASP Up messages MAY be put
under control of Layer Management. In this method, expiry of T(ack) under control of Layer Management. In this method, expiry of T(ack)
results in an M-ASP_UP confirm primitive carrying a negative results in an M-ASP_UP confirm primitive carrying a negative
indication. indication.
The ASP MUST wait for the ASP Up Ack message before sending any other The ASP MUST wait for the ASP Up Ack message before sending any other
M2UA messages (e.g., ASP Active or REG REQ). If the SGP receives any M2UA messages (e.g., ASP Active or REG REQ). If the SGP receives any
other M2UA messages before an ASP Up message is received, the SGP other M2UA messages before an ASP Up message is received (other than
SHOULD discard them. ASP Down - see Section 4.3.4.2), the SGP MAY discard them.
If an ASP Up message is received and internally the remote ASP is in If an ASP Up message is received and internally the remote ASP is in
the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
an Error message ("Unexpected Message), and the remote ASP state is an Error message ("Unexpected Message), and the remote ASP state is
changed to ASP-INACTIVE in all relevant Application Servers. changed to ASP-INACTIVE in all relevant Application Servers.
If an ASP Up message is received and internally the remote ASP is If an ASP Up message is received and internally the remote ASP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken. and no further action is taken.
4.3.4.1.1 M2UA Version Control 4.3.4.1.1 M2UA Version Control
If an ASP Up message with an unsupported version is received, the If an ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management. the receiving node supports and notifies Layer Management.
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 initiate the ASP Up procedure it is assumed that the Error message
would normally come from the SGP. would normally come from the SGP.
4.3.4.2 ASP Down Procedures 4.3.4.2 ASP Down Procedures
The ASP will send an ASP Down message to an SGP when the ASP wishes to The ASP will send an ASP Down message to an SGP when the ASP wishes to
be removed from service in all Application Servers that it is a member be removed from service in all Application Servers that it is a member
and no longer receive any MAUP or ASPTM messages. This action MAY be and no longer receive any MAUP or ASPTM messages. This action MAY be
initiated at the ASP by an M-ASP_DOWN request primitive from Layer initiated at the ASP by an M-ASP_DOWN request primitive from Layer
Management or MAY be initiated automatically by an M2UA management Management or MAY be initiated automatically by an M2UA management
function. function.
Whether the ASP is permanently removed from any AS is a function of Whether the ASP is permanently removed from any AS is a function of
configuration management. In the case where the ASP previously used configuration management. In the case where the ASP previously used
the Registration procedures (see Section 4.3.5) to register within the Registration procedures (see Section 4.4) to register within
Application Servers but has not deregistered from all of them prior to Application Servers but has not deregistered from all of them prior to
sending the ASP Down message, the SGP MUST consider the ASP as sending the ASP Down message, the SGP MUST consider the ASP as
Deregistered in all Application Servers that it is still a member. Deregistered in all Application Servers that it is still a member.
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an The SGP marks the ASP as ASP-DOWN, informs Layer Management with an
M-ASP_Down indication primitive, and returns an ASP Down Ack message M-ASP_Down indication primitive, and returns an ASP Down Ack message
to the ASP. to the ASP.
The SGP MUST send an ASP Down Ack message in response to a received ASP The SGP MUST send an ASP Down Ack message in response to a received ASP
Down message from the ASP even if the ASP is already marked as ASP-DOWN Down message from the ASP even if the ASP is already marked as ASP-DOWN
at the SGP. at the SGP.
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. If Layer Management is informed with an M-ASP_DOWN confirm primitive. If
the ASP receives an ASP Down Ack without having sent an ASP Down the ASP receives an ASP Down Ack without having sent an ASP Down
message, the ASP should now consider itself as in the ASP-DOWN state. message, the ASP SHOULD now consider itself as in the ASP-DOWN state.
If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the If the ASP was previously in the ASP-ACTIVE or ASP_INACTIVE state, the
ASP should then initiate procedures to return itself to its previous ASP SHOULD then initiate procedures to return itself to its previous
state. state.
When the ASP sends an ASP Down message it starts timer T(ack). If the When the ASP sends an ASP Down message it starts timer T(ack). If the
ASP does not receive a response to an ASP Down message within T(ack), ASP does not receive a response to an ASP Down message within T(ack),
the ASP MAY restart T(ack) and resend ASP Down messages until it the ASP MAY restart T(ack) and resend ASP Down messages until it
receives an ASP Down Ack message. T(ack) is provisionable, with a receives an ASP Down Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Down default of 2 seconds. Alternatively, retransmission of ASP Down
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 an M-ASP_DOWN confirm primitive carrying a expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a
negative indication. negative indication.
skipping to change at page 60, line 36 skipping to change at page 60, line 36
Interface Identifier") message for each invalid or unconfigured Interface Identifier") message for each invalid or unconfigured
Interface Identifer value in a received ASP Inactive message. Interface Identifer value in a received ASP Inactive message.
The SGP MUST send an ASP Inactive Ack message in response to a received The SGP MUST send an ASP Inactive Ack message in response to a received
ASP Inactive message from the ASP and the ASP is already marked as ASP- ASP Inactive message from the ASP and the ASP is already marked as ASP-
INACTIVE at the SGP. INACTIVE at the SGP.
At the ASP, the ASP Inactive Ack message received is not acknowledged. At the ASP, the ASP Inactive Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_INACTIVE confirm primitive. Layer Management is informed with an M-ASP_INACTIVE confirm primitive.
If the ASP receives an ASP Inactive Ack without having sent an ASP If the ASP receives an ASP Inactive Ack without having sent an ASP
Inactive message, the ASP should now consider itself as in the Inactive message, the ASP SHOULD now consider itself as in the
ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE
state, the ASP should then initiate procedures to return itself to state, the ASP SHOULD then initiate procedures to return itself to
its previous state. its previous state.
When the ASP sends an ASP Inactive message it starts timer T(ack). When the ASP sends an ASP Inactive message it starts timer T(ack).
If the ASP does not receive a response to an ASP Inactive message If the ASP does not receive a response to an ASP Inactive message
within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive
messages until it receives an ASP Inactive Ack message. T(ack) is messages until it receives an ASP Inactive Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively, provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M- Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication. ASP_Inactive confirm primitive carrying a negative indication.
skipping to change at page 62, line 31 skipping to change at page 62, line 31
entry, and the ASP is not currently included in the list of ASPs for entry, and the ASP is not currently included in the list of ASPs for
the related Application Server, the SGP MAY authorize the ASP to be the related Application Server, the SGP MAY authorize the ASP to be
added to the AS. Or, if the Link Key does not currently exist and the added to the AS. Or, if the Link Key does not currently exist and the
received Link Key data is valid and unique, an SGP supporting dynamic received Link Key data is valid and unique, an SGP supporting dynamic
configuration MAY authorize the creation of a new Interface Identifier configuration MAY authorize the creation of a new Interface Identifier
and related Application Server and add the ASP to the new AS. In either and related Application Server and add the ASP to the new AS. In either
case, the SGP returns a Registration Response message to the ASP, case, the SGP returns a Registration Response message to the ASP,
containing the same Local-LK-Identifier as provided in the initial containing the same Local-LK-Identifier as provided in the initial
request, a Registration Result "Successfully Registered" and the request, a Registration Result "Successfully Registered" and the
Interface Identifier. A unique method of Interface Identifier valid Interface Identifier. A unique method of Interface Identifier valid
assignment at the SG/SGP is implementation dependent but must be assignment at the SG/SGP is implementation dependent but MUST be
guaranteed to be unique for each Application server or Link Key guaranteed to be unique for each Application server or Link Key
served by SGP. served by SGP.
If the SGP determines that the received Link Key data is invalid, or If the SGP determines that the received Link Key data is invalid, or
contains invalid parameter values, the SGP returns a Registration contains invalid parameter values, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error Response message to the ASP, containing a Registration Result "Error
- Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI" - Invalid Link Key", "Error - Invalid SDTI", "Error - Invalid SDLI"
as appropriate. as appropriate.
If the SGP determins that the Link Key parameter overlaps with an If the SGP determins that the Link Key parameter overlaps with an
skipping to change at page 72, line 5 skipping to change at page 72, line 5
7.1 Threats 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 [6] provides certain transport related
security features, such as: security features, such as:
* Blind Denial of Service Attacks * Blind Denial of Service Attacks
* 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. [11] 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 MAY NOT be reasonable to expect that all parties have implemented
security in a sufficient manner. In such a case, it is recommended that security in a sufficient manner. In such a case, it is recommended that
IPSEC is used to ensure confidentiality of user payload. Consult [11] IPSEC is used to ensure confidentiality of user payload. Consult [12]
for more information on configuring IPSEC services. for more information on configuring IPSEC services.
7.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.
skipping to change at page 74, line 20 skipping to change at page 74, line 20
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
of Signalling System Number 7', Volume 1, December 1995 of Signalling System Number 7', Volume 1, December 1995
[5] UTF-8, a transformation format of ISO 10646, RFC 2279, January
1998
10.2 Informative 10.2 Informative
[5] Stream Control Transmission Protocol, RFC 2960, October 2000 [6] Stream Control Transmission Protocol, RFC 2960, October 2000
[6] Architectural Framework for Signalling Transport, RFC 2719, [7] Architectural Framework for Signalling Transport, RFC 2719,
October 1999 October 1999
[7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', [8] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer',
February 1995 February 1995
[8] ITU-T Recommendation Q.2210, 'Message transfer part level 3 [9] ITU-T Recommendation Q.2210, 'Message transfer part level 3
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 [10] ITU-T Recommendation Q.751.1, 'Network Element Management
Information Model for the Message Transfer Part', October 1995 Information Model for the Message Transfer Part', October 1995
[10] Site Security Handbook, RFC 2196, September 1997 [11] Site Security Handbook, RFC 2196, September 1997
[11] Security Architecture for the Internet Protocol, RFC 2401 [12] Security Architecture for the Internet Protocol, RFC 2401
[12] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip- [13] SCTP Dynamic Addition of IP addresses, draft-ietf-tsvwg-addip-
sctp-00.txt, Work In Progress sctp-00.txt, Work In Progress
11.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
 End of changes. 

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