draft-ietf-sigtran-m2pa-07.txt   draft-ietf-sigtran-m2pa-08.txt 
Network Working Group Tom George Network Working Group Tom George
INTERNET-DRAFT Alcatel INTERNET-DRAFT Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Ram Dantu Ram Dantu
Netrake Netrake
Malleswar Kalla
Telcordia
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Greg Sidebottom
Signatus Technologies
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Expires July 2003 January 17, 2003 Expires October 2003 April 22, 2003
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-07.txt> <draft-ietf-sigtran-m2pa-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 14 skipping to change at page 2, line 14
Abstract Abstract
This Internet Draft defines a protocol supporting the transport of This Internet Draft defines a protocol supporting the transport of
Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
signaling messages over Internet Protocol (IP) using the services of signaling messages over Internet Protocol (IP) using the services of
the Stream Control Transmission Protocol (SCTP). This protocol would the Stream Control Transmission Protocol (SCTP). This protocol would
be used between SS7 Signaling Points using the MTP Level 3 be used between SS7 Signaling Points using the MTP Level 3
protocol. The SS7 Signaling Points may also use standard SS7 links protocol. The SS7 Signaling Points may also use standard SS7 links
using the SS7 MTP Level 2 to provide transport of MTP Level 3 using the SS7 MTP Level 2 to provide transport of MTP Level 3
signaling messages. signaling messages. The protocol operates in a manner similar to MTP
Level 2 so as to provide peer-to-peer communication between SS7
endpoints.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction............................................. 4 1. Introduction............................................. 4
1.1 Scope................................................. 4 1.1 Scope................................................. 4
1.2 Terminology........................................... 4 1.2 Terminology........................................... 4
1.3 Abbreviations......................................... 5 1.3 Abbreviations......................................... 5
1.4 Conventions........................................... 6 1.4 Conventions........................................... 6
1.5 Signaling Transport Architecture...................... 6 1.5 Signaling Transport Architecture...................... 6
1.6 Services Provided by M2PA............................. 8 1.6 Services Provided by M2PA............................. 8
1.7 Functions Provided by M2PA............................ 9 1.7 Functions Provided by M2PA............................ 9
1.8 Definition of the M2PA Boundaries.....................10 1.8 Definition of the M2PA Boundaries.....................10
1.9 Differences Between M2PA and M2UA.....................11 1.9 Differences Between M2PA and M2UA.....................11
2. Protocol Elements........................................13 2. Protocol Elements........................................13
2.1 Common Message Header.................................13 2.1 Common Message Header.................................13
2.2 M2PA Header...........................................15 2.2 M2PA Header...........................................14
2.3 M2PA Messages.........................................15 2.3 M2PA Messages.........................................15
3. M2PA Link State Control..................................19 3. State Control............................................19
4. Procedures...............................................23 3.1 SCTP Association State Control........................19
4.1 Procedures to Support MTP2 Features...................23 3.2 M2PA Link State Control...............................20
4.2 Procedures to Support the MTP3/MTP2 Interface.........32 4. Procedures...............................................21
4.3 SCTP Considerations...................................37 4.1 Procedures to Support MTP2 Features...................21
5. Examples of M2PA Procedures..............................39 4.2 Procedures to Support the MTP3/MTP2 Interface.........29
5.1 Link Initialization (Alignment).......................39 4.3 SCTP Considerations...................................32
5.2 Message Transmission and Reception....................42 5. Examples of M2PA Procedures..............................34
5.3 Link Status Indication................................42 5.1 Link Initialization (Alignment).......................34
5.4 Link Status Message (Processor Outage)................43 5.2 Message Transmission and Reception....................37
5.5 Level 2 Flow Control..................................44 5.3 Link Status Indication................................37
5.6 MTP3 Signaling Link Congestion........................46 5.4 Link Status Message (Processor Outage)................38
5.7 Link Deactivation.....................................47 5.5 Level 2 Flow Control..................................39
5.8 Link Changeover.......................................48 5.6 MTP3 Signaling Link Congestion........................41
6. Security.................................................50 5.7 Link Deactivation.....................................42
6.1 Threats...............................................50 5.8 Link Changeover.......................................43
6.2 Protecting Confidentiality............................50 6. Security.................................................44
7. IANA Considerations......................................51 6.1 Threats...............................................44
7.1 SCTP Payload Protocol Identifier......................51 6.2 Protecting Confidentiality............................44
7.2 M2PA Protocol Extensions..............................51 7. IANA Considerations......................................45
8. Acknowledgements.........................................53 7.1 SCTP Payload Protocol Identifier......................45
9. References...............................................53 7.2 M2PA Protocol Extensions..............................45
10. Author's Addresses.......................................55 8. Acknowledgements.........................................46
9. References...............................................47
9.1 Normative..............................................47
9.2 Informative............................................48
10. Author's Addresses.......................................49
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 over an IP network. This includes message transfer between delivery over an IP network. This includes message transfer between
the following: the following:
- a Signaling Gateway (SG) and a Media Gateway Controller (MGC) - a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
skipping to change at page 6, line 13 skipping to change at page 6, line 13
SLC - Signaling Link Code SLC - Signaling Link Code
SS7 - Signaling System Number 7 SS7 - Signaling System Number 7
SSN - Stream Sequence Number SSN - Stream Sequence Number
STP - Signal Transfer Point STP - Signal Transfer Point
1.4 Conventions 1.4 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
appear in this document, are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.5 Signaling Transport Architecture 1.5 Signaling Transport Architecture
The architecture that has been defined [RFC2719] for Switched Circuit The architecture that has been defined [RFC2719] for Switched Circuit
Network (SCN) signaling transport over IP uses multiple components, Network (SCN) signaling transport over IP uses multiple components,
including an IP transport protocol, the Stream Control Transmission including an IP transport protocol, the Stream Control Transmission
Protocol (SCTP), and an adaptation module to support the services Protocol (SCTP), and an adaptation module to support the services
expected by a particular SCN signaling protocol from its underlying expected by a particular SCN signaling protocol from its underlying
protocol layer. protocol layer.
Within this framework architecture, this document defines an SCN Within this framework architecture, this document defines an SCN
adaptation module that is suitable for the transport of SS7 MTP3 adaptation module that is suitable for the transport of SS7 MTP3
messages. messages. The adaptation layer, known as the MTP2 User Peer-to-peer
Adaptation Layer (M2PA), provides MTP3 with an interface and services
similar to MTP2. In effect, MTP2 and lower layers of the traditional
SS7 protocol stack are replaced by an IP equivalent.
Figure 1 shows the seamless interworking at the MTP3 layer. MTP3 is Figure 1 shows the seamless interworking at the MTP3 layer. MTP3 is
adapted to the SCTP layer using the MTP2 User Peer-to-peer Adaptation adapted to the SCTP layer using the MTP2 User Peer-to-peer Adaptation
Layer (M2PA). All the primitives between MTP3 and MTP2 are supported Layer (M2PA). All the primitives between MTP3 and MTP2 are supported
by M2PA. The SCTP association acts as one SS7 link between the IPSPs. by M2PA. The SCTP association acts as one SS7 link between the IPSPs.
An IPSP may have the Signaling Connection Control Part (SCCP) and An IPSP may have the Signaling Connection Control Part (SCCP) and
other SS7 layers above MTP3. other SS7 layers above MTP3.
******** IP ******** ******** IP ********
* IPSP *--------* IPSP * * IPSP *--------* IPSP *
skipping to change at page 7, line 31 skipping to change at page 7, line 31
+------+ +------+ +------+ +------+
IP - Internet Protocol IP - Internet Protocol
IPSP - IP Signaling Point IPSP - IP Signaling Point
SCTP - Stream Control Transmission Protocol [RFC2960] SCTP - Stream Control Transmission Protocol [RFC2960]
Figure 1. M2PA Symmetrical Peer-to-Peer Architecture Figure 1. M2PA Symmetrical Peer-to-Peer Architecture
Figure 2 shows an example of M2PA used in a Signaling Gateway Figure 2 shows an example of M2PA used in a Signaling Gateway
(SG). The SG is an IPSP equipped with both traditional SS7 and IP (SG). The SG is an IPSP equipped with both traditional SS7 and IP
network connections. In effect, the Signaling Gateway acts as a network connections. Any of the nodes in the diagram could have SCCP
Signal Transfer Point (STP). Any of the nodes in the diagram could or other SS7 layers above MTP3. The Signaling Gateway acts as a Signal
have SCCP or other SS7 layers. STPs MAY or MAY NOT be present in the Transfer Point (STP). Other STPs MAY be present in the SS7 path
SS7 path between the SEP and the SG. between the SEP and the SG.
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP * * SEP *--------* SG *--------* IPSP *
******** *************** ******** ******** *************** ********
+------+ +------+ +------+ +------+
| TCAP | | TCAP | | TCAP | | TCAP |
+------+ +------+ +------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+ +------+ +-------------+ +------+
skipping to change at page 8, line 11 skipping to change at page 8, line 33
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
Figure 2. M2PA in IP Signaling Gateway Figure 2. M2PA in IP Signaling Gateway
Figure 2 is only an example. Other configurations are possible. In Figure 2 is only an example. Other configurations are possible. In
short, M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP short, M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP
stack can be used in place of an MTP2/MTP1 stack. stack can be used in place of an MTP2/MTP1 stack.
1.5.1 Point Code Representation 1.5.1 Point Code Representation
The MTP specification requires that each node with an MTP3 layer is MTP requires that each node with an MTP3 layer is identified by an SS7
identified by an SS7 point code. In particular, each IPSP MUST have point code. In particular, each IPSP MUST have its own SS7 point code.
its own SS7 point code.
1.6 Services Provided by M2PA 1.6 Services Provided by M2PA
The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The
M2PA protocol layer is required to provide the equivalent set of M2PA protocol layer is required to provide the equivalent set of
services to its user as provided by MTP Level 2 to MTP Level 3. services to its user as provided by MTP Level 2 to MTP Level 3.
These services are described in the following subsections. These services are described in the following subsections.
1.6.1 Support for MTP Level 2 / MTP Level 3 interface boundary 1.6.1 Support for MTP Level 2 / MTP Level 3 interface boundary
This interface is the same as the MTP2/MTP3 interface described in This interface is the same as the MTP2/MTP3 interface described in the
[Q.703], [Q.704], [T1.111], and [Q.2140], with the addition of support applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140], with the
for larger sequence numbers in [T1.111] and [Q.2210]. addition of support for larger sequence numbers in [T1.111] and
[Q.2210].
M2PA receives the primitives sent from MTP3 to its lower layer. M2PA
processes these primitives or maps them to appropriate primitives at
the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like
those used in the MTP3/MTP2 interface.
Because M2PA uses larger sequence numbers than MTP2, the MTP3 Because M2PA uses larger sequence numbers than MTP2, the MTP3
Changeover procedure MUST use the Extended Changeover Order and Changeover procedure MUST use the Extended Changeover Order and
Extended Changeover Acknowledgment messages described in [Q.2210] and Extended Changeover Acknowledgment messages described in [Q.2210] and
[T1.111]. [T1.111].
Also, the following MTP3/MTP2 primitives must use the larger sequence Also, the following MTP3/MTP2 primitives must use the larger sequence
numbers: numbers:
- BSNT Confirmation - BSNT Confirmation
skipping to change at page 9, line 5 skipping to change at page 9, line 32
MSUs originate at a higher level than MTP2, and are destined for a MSUs originate at a higher level than MTP2, and are destined for a
peer at another node. Likewise, M2PA passes these messages from MTP3 peer at another node. Likewise, M2PA passes these messages from MTP3
to SCTP as data for transport across a link. These are called User to SCTP as data for transport across a link. These are called User
Data messages in M2PA. Data messages in M2PA.
LSSUs allow peer MTP2 layers to exchange status information. Analogous LSSUs allow peer MTP2 layers to exchange status information. Analogous
messages are needed for M2PA. The Link Status message serves this messages are needed for M2PA. The Link Status message serves this
purpose. purpose.
FISUs are sent when no other signal units are waiting to be sent. This FISUs are transmitted continuously when no other signal units are
purpose is served by the heartbeat messages in SCTP. FISUs also carry waiting to be sent. FISUs also carry acknowledgment of messages. Since
acknowledgment of messages. This function is performed by the M2PA an IP network is a shared resource, it would be undesirable to have a
User Data message. Therefore, it is unnecessary for M2PA to provide a message type that is sent continuously as the FISUs are. Furthermore,
protocol data unit like the FISU. Furthermore, since an IP network is SCTP does not require its upper layer to continuously transmit
a shared resource, it would be undesirable to have a message type that messages. Therefore, M2PA does not provide a protocol data unit like
is sent continuously as the FISUs are. the FISU. The M2PA User Data message is used to carry acknowledgment
of messages. If M2PA needs to acknowledge a message and it has no MTP3
message of its own to send, an empty User Data message can be sent.
1.7 Functions Provided by M2PA 1.7 Functions Provided by M2PA
1.7.1 Support of MTP3/MTP2 Primitives 1.7.1 MTP2 Functionality
M2PA receives the primitives sent from MTP3 to its lower layer. M2PA M2PA provides MTP2 functionality that is not provided by SCTP, so that
processes these primitives or maps them to appropriate primitives at together M2PA and SCTP provide functionality similar to that of
the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like MTP2.
those used in the MTP3/MTP2 interface.
1.7.2 MTP2 Functionality SCTP provides reliable, sequenced delivery of messages.
M2PA provides MTP2 functionality that is not provided by SCTP. This M2PA functionality includes:
includes
- Data retrieval to support the MTP3 changeover procedure - Data retrieval to support the MTP3 changeover procedure
- Reporting of link status changes to MTP3 - Reporting of link status changes to MTP3
- Processor outage procedure - Processor outage procedure
- Link alignment procedure - Link alignment procedure
SCTP provides reliable, sequenced delivery of messages. 1.7.2 Mapping of SS7 and IP Entities
1.7.3 Mapping of SS7 and IP Entities
The M2PA layer must maintain a map of each of its SS7 links to the The M2PA layer must maintain a map of each of its SS7 links to the
corresponding SCTP association. corresponding SCTP association.
1.7.4 SCTP Stream Management 1.7.3 SCTP Association Management
SCTP allows a user-specified number of streams to be opened during the SCTP allows a user-specified number of streams to be opened during the
initialization. It is the responsibility of the M2PA layer to ensure initialization. It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association. proper management of the streams allowed within each association.
M2PA uses two streams in each direction for each association. Stream 0 M2PA uses two streams in each direction for each association. Stream 0
in each direction is designated for Link Status messages. Stream 1 is in each direction is designated for Link Status messages. Stream 1 is
designated for User Data messages. Separating the Link Status and User designated for User Data messages. Separating the Link Status and User
Data messages onto separate streams allows M2PA to prioritize the Data messages onto separate streams allows M2PA to prioritize the
messages in a manner similar to MTP2. messages in a manner similar to MTP2.
1.7.5 Retention of MTP3 in the SS7 Network Notifications received from SCTP are processed by M2PA or translated
into an appropriate notification to be sent to the upper layer MTP3.
1.7.4 Retention of MTP3 in the SS7 Network
M2PA allows MTP3 to perform all of its Message Handling and Network M2PA allows MTP3 to perform all of its Message Handling and Network
Management functions with IPSPs as with other SS7 nodes. Management functions with IPSPs as with other SS7 nodes.
1.8 Definition of the M2PA Boundaries 1.8 Definition of the M2PA Boundaries
1.8.1 Definition of the M2PA / MTP Level 3 boundary 1.8.1 Definition of the M2PA / MTP Level 3 boundary
The upper layer primitives provided by M2PA are the same as those The upper layer primitives provided by M2PA are the same as those
provided by MTP2 to MTP3. These primitives are described in [Q.703], provided by MTP2 to MTP3. These primitives are described in the
[Q.704], [T1.111], and [Q.2140]. Following is a list of the applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140].
primitives.
Primitives sent from MTP3 to M2PA:
Data Request - Used to send a Data Message for transmission.
Start Request - Used to activate a link.
Stop Request - Used to deactivate a link.
Retrieve BSNT Request - Request the BSNT for the changeover
procedure.
Retrieval Request and FSNC - Request retrieval of unacknowledged
and unsent messages. This request includes the FSNC received from
the remote end.
Local Processor Outage Request - Informs M2PA of a local processor
outage condition.
Local Processor Outage Recovered Request - Informs M2PA that a
local processor outage condition has ceased.
Flush Buffers Request - Requests that all transmit and receive
buffers be emptied.
Continue Request - Requests that processing resume after a
processor outage.
Emergency Request - Requests that M2PA use the emergency alignment
procedure.
Emergency Ceases Request - Requests that M2PA use the normal
alignment procedure.
Primitives sent from M2PA to MTP3:
Data Indication - Used to deliver received Data Message to MTP3.
Congestion Indication - Indicates change in congestion status. The
indication includes the congestion status, if the protocol is using
the optional congestion levels. The indication also includes the
discard status.
In Service Indication - Indicates that the link is in service.
Out of Service Indication - Indicates that the link is out of
service.
Retrieved Messages Indication - Indicates delivery of
unacknowledged and unsent messages.
Retrieval Complete Indication - Indicates that delivery of
unacknowledged and unsent messages is complete.
BSNT Confirm - Replies to the BSNT Request. The confirmation
includes the BSNT.
BSNT Not Retrievable Confirm - Replies to the BSNT Request when the
BSNT cannot be determined.
Remote Processor Outage Indication - Indicates processor outage at
remote end.
Remote Processor Recovered Indication - Indicates recovery from
processor outage at remote end.
1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP 1.8.2 Definition of the Lower Layer Boundary between M2PA and SCTP
The upper layer primitives provided by SCTP are described in [RFC2960] The upper layer primitives provided by SCTP are described in [RFC2960]
Section 10 "Interface with Upper Layer". Section 10 "Interface with Upper Layer".
1.9 Differences Between M2PA and M2UA 1.9 Differences Between M2PA and M2UA
The MTP2 User Adaptation Layer (M2UA) [M2UA] also adapts the MTP3 layer The MTP2 User Adaptation Layer (M2UA) [M2UA] also adapts the MTP3
to the SCTP/IP stack. It does so through a backhauling architecture layer to the SCTP/IP stack. It does so through a backhauling
[RFC2719]. This section intends to clarify some of the differences architecture [RFC2719]. This section is intended to clarify some of
between the M2PA and M2UA approaches. the differences between the M2PA and M2UA approaches.
A possible M2PA architecture is shown in Figure 3. Here the IPSP's A possible M2PA architecture is shown in Figure 3. Here the IPSP's
MTP3 uses its underlying M2PA as a replacement for MTP2. Communication MTP3 uses its underlying M2PA as a replacement for MTP2. Communication
between the two layers MTP3/M2PA is defined by the same primitives as between the two layers MTP3/M2PA is defined by the same primitives as
in SS7 MTP3/MTP2. M2PA performs functions similar to MTP2. in SS7 MTP3/MTP2. M2PA performs functions similar to MTP2.
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP * * SEP *--------* SG *--------* IPSP *
******** *************** ******** ******** *************** ********
skipping to change at page 15, line 25 skipping to change at page 14, line 38
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | BSN | | unused | BSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | FSN | | unused | FSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. M2PA-specific Message Header Figure 6. M2PA-specific Message Header
2.2.1 Backward Sequence Number 2.2.1 Backward Sequence Number (BSN)
This is the FSN of the message last received from the peer. This is the FSN of the message last received from the peer.
2.2.2 Forward Sequence Number 2.2.2 Forward Sequence Number (FSN)
This is the M2PA sequence number of the User Data message being sent. This is the M2PA sequence number of the User Data message being sent.
The FSN and BSN values range from 0 to 16,777,215.
2.3 M2PA Messages 2.3 M2PA Messages
The following section defines the messages and parameter contents. An The following section defines the messages and parameter contents. An
M2PA message consists of a Common Message Header and M2PA Header M2PA message consists of a Common Message Header and M2PA Header
followed by the data appropriate to the message. followed by the data appropriate to the message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Common Message Header / / Common Message Header /
\ \ \ \
skipping to change at page 16, line 31 skipping to change at page 15, line 51
Unit (MSU): Unit (MSU):
- Length Indicator (LI), including the two undefined bits between - Length Indicator (LI), including the two undefined bits between
the SIO and LI fields. the SIO and LI fields.
- Service Information Octet (SIO) - Service Information Octet (SIO)
- Signaling Information Field (SIF) - Signaling Information Field (SIF)
The MTP MSU is described in Q.703 [Q.703], section 2.2 "Signal Unit The MTP MSU is described in Q.703 [Q.703], section 2.2 "Signal Unit
Format", and T1.111.3 [T1.111] section 2.2 "Signal Unit Format". Format", and T1.111.3 [T1.111] section 2.2 "Signal Unit Format".
M2PA does not add padding to the MTP3 message. M2PA SHALL NOT add padding to the MTP3 message.
Note that the Data field SHALL NOT contain other components of the MTP Note that the Data field SHALL NOT contain other components of the MTP
MSU format: MSU format:
- Flag - Flag
- Backward Sequence Number (BSN) - Backward Sequence Number (BSN)
- Backward Indicator Bit (BIB) - Backward Indicator Bit (BIB)
- Forward Sequence Number (FSN) - Forward Sequence Number (FSN)
- Forward Indicator Bit (FIB) - Forward Indicator Bit (FIB)
- Check bits (CK) - Check bits (CK)
skipping to change at page 18, line 21 skipping to change at page 17, line 47
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Value Value
(decimal) Description (decimal) Description
--------- ----------- --------- -----------
1 Alignment 1 Alignment
2 Proving Normal 2 Proving Normal
3 Proving Emergency 3 Proving Emergency
4 Ready 4 Ready
5 Processor Outage 5 Processor Outage
6 Processor Outage Ended 6 Processor Recovered
7 Busy 7 Busy
8 Busy Ended 8 Busy Ended
9 Out of Service (OOS) 9 Out of Service (OOS)
2.3.2.1 Link Status Proving 2.3.2.1 Link Status Proving
The Link Status Proving message may optionally carry additional The Link Status Proving message may optionally carry additional
bytes. If the optional bytes are used, the format for the message is bytes. If the optional bytes are used, the format for the message is
as follows. as follows.
skipping to change at page 18, line 48 skipping to change at page 18, line 27
/ filler / / filler /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is RECOMMENDED that the length of the Link Status Proving message It is RECOMMENDED that the length of the Link Status Proving message
be similar to the size of the User Data messages that will be carried be similar to the size of the User Data messages that will be carried
on the link. on the link.
It is RECOMMENDED that the filler field contain a number pattern which It is RECOMMENDED that the filler field contain a number pattern which
varies among the Link Status Proving messages, and that will allow the varies among the Link Status Proving messages, and that will allow the
SCTP checksum to be used to verify the accuracy of transmission. SCTP checksum [RFC3309] to be used to verify the accuracy of
transmission.
3. M2PA Link State Control
The M2PA link moves from one state to another in response to various
events. The events that may result in a change of state include:
- MTP3 primitive requests
- SCTP notifications
- Receipt of Link Status messages from the peer M2PA
- Expiration of certain timers
Figure 7 illustrates state changes together with the causing events.
Note that some of the error conditions are not shown in the state
diagram.
Following is a list of the M2PA Link States and a description of each.
POWER OFF - State of the link during power-up initialization.
OUT OF SERVICE (OOS) - Out of service. Power-up initialization is
complete.
INITIAL ALIGNMENT - Alignment in Progress. M2PA is attempting to
exchange Link Status Alignment messages with its peer.
PROVING - M2PA is sending Link Status Proving messages to its peer.
ALIGNED READY - Proving is complete. M2PA is waiting until peer
completes proving.
IN SERVICE (INS) - In service. Link is ready for traffic.
ALIGNED NOT READY - A local processor outage condition began before
the alignment and proving procedure was completed.
PROCESSOR OUTAGE - A local processor outage condition began while
the link was in service.
+-----------+ 3. State Control
| POWER |
| OFF |
+-----------+
|
| Power On
|
Flush Buffers | +-------------------------+
OR Retrieval | | |
+-------+ | | |
| | V V |
| +-----------+ |
+--->| OUT OF | |
+---------------->| SERVICE |<--+ |
| +-----------+ | Link Configured |
| | | | (Associate) |
| | +-----+ |
| | |
| | MTP3 Start |
| V |
| +-----------+ |
| | INITIAL | |
+<----------------| ALIGNMENT |--------------------->+
| MTP3 Stop +-----------+ SCTP Comm Error |
| OR T2 Expiry | ^ OR SCTP Comm Lost |
| OR Receive LS OOS | | |
| | +-------------------------|--------+
| | LPO/LPR | |
| | | |
| | Receive LS Align | |
| | | |
| V | |
| +-----------+ LPO/LPR | |
| | PROVING |<---------------------|--------+
|<----------------| |--------------------->+ |
| MTP3 Stop +-----------+ SCTP Comm Error | |
| OR T3 Expiry | OR SCTP Comm Lost | |
| OR Receive LS OOS | | |
| | T4 Expiry | |
| | Send LS Ready | |
| V | V
| +-----------+ LPO/LPR | +-----------+
| | ALIGNED |<---------------------|->| ALIGNED |
+<----------------| READY |--------------------->+ | NOT READY |
| MTP3 Stop +-----------+ SCTP Comm Error +-----------+
| OR T1 Expiry | OR SCTP Comm Lost | |
| OR Receive LS OOS | | T1 |
| OR Receive LS Align | Receive LS Ready Receive | Expiry|
| | OR Receive User Data LS Ready | OR Rcv|
| | OR Receive | LS |
| | LS PO | Align|
| | | |
| | | |
| | | |
| V V |
| +-----------+ LPO/LPR +-----------+ |
| | IN |<-------------------->| PROCESSOR | |
| | SERVICE | | OUTAGE | |
| +-----------+ +-----------+ |
| | | |
| MTP3 Stop | MTP3 Stop | |
| OR Receive LS OOS | OR Receive LS OOS | |
| OR SCTP Comm Error | OR SCTP Comm Error | |
| OR SCTP Comm Lost | OR SCTP Comm Lost | |
| OR T6 Expiry | OR M2PA Link Failure | |
| OR T7 Expiry | OR Receive LS Align | |
| OR M2PA Link Failure | | |
| OR Receive LS Align | | |
| V V V
+<----------------------+<---------------------------------+-------+
Figure 7. M2PA Link State Transition Diagram 3.1 SCTP Association State Control
Figure 8 illustrates state changes in the M2PA management of the SCTP Figure 7 illustrates state changes in the M2PA management of the SCTP
association together with the causing events. Note that some of the association together with the causing events. Note that some of the
error conditions are not shown in the state diagram. error conditions are not shown in the state diagram.
Following is a list of the M2PA Association States and a description Following is a list of the M2PA Association States and a description
of each. of each.
IDLE - State of the association during power-up initialization. IDLE - State of the association during power-up initialization.
ASSOCIATE - M2PA is attempting to establish an SCTP association. ASSOCIATE - M2PA is attempting to establish an SCTP association.
skipping to change at page 22, line 28 skipping to change at page 19, line 45
| | | |
| | | |
| SCTP Comm Up | | SCTP Comm Up |
| | | |
V | V |
+-------------+ | +-------------+ |
| ESTABLISHED |----------------->+ | ESTABLISHED |----------------->+
+-------------+ SCTP Comm Error +-------------+ SCTP Comm Error
OR SCTP Comm Lost OR SCTP Comm Lost
Figure 8. M2PA Association State Transition Diagram Figure 7. M2PA Association State Transition Diagram
3.2 M2PA Link State Control
The M2PA link moves from one state to another in response to various
events. The events that may result in a change of state include:
- MTP3 primitive requests
- Receipt of messages from the peer M2PA
- Expiration of timers
- SCTP notifications
These events affect the M2PA link state in a manner similar to MTP2.
4. Procedures 4. Procedures
Since M2PA provides MTP3 with an interface and functionality like
MTP2, its internal functioning is similar to that of MTP2.
Except as modified in this document, M2PA SHOULD follow the
requirements of the applicable MTP2 specification. These may include
[Q.703] or [T1.111].
When referring to MTP2 terminology in this document, the terminology
of [Q.703] is used. This does not imply that the requirements of
[Q.703] are to be followed.
4.1 Procedures to Support MTP2 Features 4.1 Procedures to Support MTP2 Features
4.1.1 Signal Unit Format, Delimitation, Acceptance 4.1.1 Signal Unit Format, Delimitation, Acceptance
Messages for transmission across the network must follow the format Messages for transmission across the network must follow the format
described in section 2. described in section 2.
SCTP provides reliable, in-sequence delivery. Therefore the related SCTP provides reliable, in-sequence delivery of user
functionality of MTP2 is not needed. SCTP does not provide functions messages. Therefore the related functionality of MTP2 is not
related to Link State Control in MTP2. These functions must be needed. SCTP does not provide functions related to Link State Control
provided by M2PA. in MTP2. These functions must be provided by M2PA.
Since SCTP provides delivery of messages, there is no need for M2PA to
delimit its messages with a flag as in MTP2. Furthermore, M2PA does
not need to perform zero bit insertion and deletion on its messages.
Since SCTP uses a checksum to detect transmission errors, there is no
need for an M2PA checksum as in MTP2. This also eliminates the need
for the error rate monitors of MTP2.
Since SCTP provides reliable delivery and ordered delivery, M2PA does
not perform retransmissions. This eliminates the need for the forward
and backward indicator bits in MTP2 signal units.
Acceptance of a message is indicated by a successful receipt of the
message from SCTP.
4.1.2 MTP and SCTP Entities 4.1.2 MTP and SCTP Entities
This section describes how M2PA relates MTP and SCTP entities. This section describes how M2PA relates MTP and SCTP entities.
Each MTP link corresponds to an SCTP association. To prevent duplicate Each MTP link corresponds to an SCTP association. To prevent duplicate
associations from being established, it is RECOMMENDED that each associations from being established, it is RECOMMENDED that each
endpoint know the IP address (or IP addresses, if multi-homing is endpoint know the IP address (or IP addresses, if multi-homing is
used) and port number of both endpoints. SCTP prevents two used) and port number of both endpoints. SCTP prevents two
associations with the same IP addresses and port numbers from being associations with the same IP addresses and port numbers from being
skipping to change at page 23, line 55 skipping to change at page 22, line 41
association) MUST be mapped to the same Signaling Link Code (SLC) at association) MUST be mapped to the same Signaling Link Code (SLC) at
each endpoint, so that each endpoint knows which link is being created each endpoint, so that each endpoint knows which link is being created
at the time the SCTP association is established. However, M2PA does at the time the SCTP association is established. However, M2PA does
not do any processing based on the SLC. not do any processing based on the SLC.
Following are examples of the relationships between associations and Following are examples of the relationships between associations and
links. Note that a link is an SCTP association identified by two links. Note that a link is an SCTP association identified by two
endpoints. Each endpoint is identified by an IP address and port endpoints. Each endpoint is identified by an IP address and port
number. Each association is mapped to an SLC. number. Each association is mapped to an SLC.
Figure 9 shows a case with two IPSPs, each with two IP addresses. Two Figure 8 shows a case with two IPSPs, each with two IP addresses. Two
associations are the links that connect the two IPSPs. Since these associations are the links that connect the two IPSPs. Since these
links are in the same link set, they MUST have different SLCs. links are in the same link set, they MUST have different SLCs.
Table 1 shows the relationships in tabular form. Table 1 is only Table 1 shows the relationships in tabular form. Table 1 is only
conceptual. The actual method for mapping the SCTP associations to the conceptual. The actual method for mapping the SCTP associations to the
SLCs is implementation dependent. SLCs is implementation dependent.
IPSP X IPSP Y IPSP X IPSP Y
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 24, line 29 skipping to change at page 23, line 25
| IPC | association 2 | IPD | | IPC | association 2 | IPD |
| port = PW +---------------+ port = PW | | port = PW +---------------+ port = PW |
| SLC = b | | SLC = b | | SLC = b | | SLC = b |
| | | | | | | |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
IPx = IP address IPx = IP address
PW = Registered port number for M2PA PW = Registered port number for M2PA
Figure 9. Two IPSPs with Two IP Addresses Each Figure 8. Two IPSPs with Two IP Addresses Each
Table 1. Two IPSPs with Two IP Addresses Each Table 1. Two IPSPs with Two IP Addresses Each
+-------------+---------------------------------------+-----+ +-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC | | Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | | | | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+ +=============+============+======+============+======+=====+
| 1 | IPA | PW | IPB | PW | a | | 1 | IPA | PW | IPB | PW | a |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
| 2 | IPC | PW | IPD | PW | b | | 2 | IPC | PW | IPD | PW | b |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
Figure 10 and Table 2 show an example with three IPSPs. Note that in Figure 9 and Table 2 show an example with three IPSPs. Note that in
this example, the two links are in different link sets. Therefore, it this example, the two links are in different link sets. Therefore, it
is possible that the values a and b MAY be equal. is possible that the values a and b MAY be equal.
IPSP X IPSP Y IPSP X IPSP Y
+-------------+ +-------------+ +-------------+ +-------------+
| | SCTP | | | | SCTP | |
| IPA | association 1 | IPB | | IPA | association 1 | IPB |
| port = PW +---------------+ port = PW | | port = PW +---------------+ port = PW |
| SLC = a | | SLC = a | | SLC = a | | SLC = a |
skipping to change at page 25, line 47 skipping to change at page 24, line 43
| | | |
| | | |
| | | |
| | | |
| | | |
+-------------+ +-------------+
IPx = IP address IPx = IP address
PW = Registered port number for M2PA PW = Registered port number for M2PA
Figure 10. One IPSP Connected to Two IPSPs Figure 9. One IPSP Connected to Two IPSPs
Table 2. One IPSP Connected to Two IPSPs Table 2. One IPSP Connected to Two IPSPs
+-------------+---------------------------------------+-----+ +-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y/Z | SLC | | Association | IPSP X | IPSP Y/Z | SLC |
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | | | | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+ +=============+============+======+============+======+=====+
| 1 | IPA | PW | IPB | PW | a | | 1 | IPA | PW | IPB | PW | a |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
| 2 | IPC | PW | IPD | PW | b | | 2 | IPC | PW | IPD | PW | b |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
Figure 11 and Table 3 show two associations between the same IP Figure 10 and Table 3 show two associations between the same IP
addresses. This is accomplished by using different port numbers for addresses. This is accomplished by using different port numbers for
each association at one endpoint. each association at one endpoint.
IPSP X IPSP Y IPSP X IPSP Y
+-------------+ +-------------+ +-------------+ +-------------+
| | SCTP | | | | SCTP | |
| IPA | association 1 | IPB | | IPA | association 1 | IPB |
| port = P1 +---------------+ port = PW | | port = P1 +---------------+ port = PW |
| SLC = a | | SLC = a | | SLC = a | | SLC = a |
skipping to change at page 26, line 41 skipping to change at page 25, line 30
| port = PW +---------------+ port = PW | | port = PW +---------------+ port = PW |
| SLC = b | | SLC = b | | SLC = b | | SLC = b |
| | | | | | | |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
IPx = IP address IPx = IP address
P1 = Pre-selected port number P1 = Pre-selected port number
PW = Registered port number for M2PA PW = Registered port number for M2PA
Figure 11. Multiple Associations Between Two IP Addresses Figure 10. Multiple Associations Between Two IP Addresses
Table 3. Multiple Associations Between Two IP Addresses Table 3. Multiple Associations Between Two IP Addresses
+-------------+---------------------------------------+-----+ +-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC | | Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | | | | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+ +=============+============+======+============+======+=====+
| 1 | IPA | P1 | IPB | PW | a | | 1 | IPA | P1 | IPB | PW | a |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
skipping to change at page 27, line 25 skipping to change at page 26, line 21
sent before the other end is ready. sent before the other end is ready.
(2) To verify that the SCTP association is suitable for use as an (2) To verify that the SCTP association is suitable for use as an
SS7 link. SS7 link.
Link alignment takes place after the association is established. If Link alignment takes place after the association is established. If
SCTP fails to establish the association, and M2PA has received a Start SCTP fails to establish the association, and M2PA has received a Start
Request from its MTP3, then M2PA SHALL report to MTP3 that the link is Request from its MTP3, then M2PA SHALL report to MTP3 that the link is
out of service. out of service.
After the association is established, M2PA SHALL send a Link Status The Link Status Out of Service message replaces the SIOS message of
Out of Service message to its peer. MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. After the association is established, M2PA SHALL send a
Once the association is established and M2PA has received a Start Link Status Out of Service message to its peer. Prior to the beginning
Request from MTP3, M2PA sends the Link Status Alignment message to its of alignment, M2PA MAY send additional Link Status Out of Service
peer. If M2PA has not already received the Link Status Alignment messages.
message from its peer, then M2PA starts timer T2.
(Note that if the remote M2PA has not received a Start Request from
its MTP3, it will not send the Link Status Alignment message to the
local M2PA. Eventually timer T2 in the local M2PA will expire. If the
remote M2PA receives a Start Request from its MTP3 and sends Link
Status Alignment before the local M2PA's timer T2 expires, the
alignment procedure can continue.)
M2PA stops timer T2 when it has received the Link Status Alignment
message from its peer.
If timer T2 expires, then M2PA reports to MTP3 that the link is out of
service. M2PA sends Link Status Out of Service to its peer. M2PA
SHOULD leave the association established. M2PA waits for MTP3 to
initiate the alignment procedure again.
Note: Between the time M2PA sends Link Status Alignment to its peer
and receives Link Status Alignment from its peer, M2PA may receive
Link Status Out of Service from its peer. This message is
ignored. After receiving Link Status Alignment from the peer, receipt
of a Link Status Out of Service message causes M2PA to send Out of
Service to MTP3 and return to the Out of Service state.
When M2PA has both sent and received the Link Status Alignment
message, it has completed alignment. M2PA starts the aligned timer T3
and moves to the proving state.
M2PA stops timer T3 when it receives a Proving Normal or Proving The Link Status Alignment message replaces the SIO message of
Emergency message and starts proving period timer T4. MTP2. This message is sent to signal the beginning of the alignment
procedure. The Link Status Alignment message SHOULD NOT be transmitted
continuously. M2PA MAY send additional Link Status Alignment until it
receives Link Status Alignment, Link Status Proving Normal, or Link
Status Proving Emergency from the peer.
If timer T3 expires, then M2PA reports to MTP3 that the link is out of The Link Status Proving Normal message replaces the SIN message of
service. M2PA sends Link Status Out of Service to its peer. M2PA MTP2. The Link Status Proving Emergency message replaces the SIE
SHOULD leave the association established. M2PA waits for MTP3 to message of MTP2.
initiate the alignment procedure again.
During the proving period (i.e., after M2PA starts the proving period During the proving period (i.e., after M2PA starts the proving period
timer T4), M2PA sends Link Status Proving messages to its peer at an timer T4), M2PA SHALL send Link Status Proving messages to its peer at
interval defined by the protocol parameter Proving_Interval. M2PA an interval defined by the protocol parameter Proving_Interval.
sends either the Proving Normal or Proving Emergency message,
according to the Emergency and Emergency Ceases commands from
MTP3. M2PA uses the value of T4 corresponding to the Normal or
Emergency condition. However, if M2PA receives a Link Status Proving
Emergency message from its peer, then M2PA SHALL initiate the
Emergency proving period value for T4, but it SHALL continue to send
the Proving message (Normal or Emergency) determined by its own upper
layer MTP3.
When the proving period timer T4 expires, M2PA changes to the Aligned
Ready state. M2PA SHALL start the timer T1 and send a Link Status
Ready message to its peer. These Link Status Ready message is used to
verify that both ends have completed proving. M2PA MAY send additional
Link Status Ready messages while timer T1 is running.
M2PA SHALL stop timer T1 when it receives a Link Status Ready or User
Data message from its peer. If timer T1 expires, then M2PA reports to
MTP3 that the link is out of service. M2PA sends Link Status Out of
Service to its peer. M2PA SHOULD leave the association
established. M2PA waits for MTP3 to initiate the alignment procedure
again.
Note that if M2PA has already received a Link Status Ready message
from its peer when its timer T4 expires, there is no need to start
timer T1. M2PA can just send Link Status Ready to the peer and
continue along.
When all of the following are true:
(a) M2PA has received a Start Request from MTP3.
(b) M2PA's proving period T4 has expired.
(c) M2PA has sent a Link Status Ready to its peer.
(d) M2PA has received a Link Status Ready OR User Data
message from its peer.
(e) M2PA has not received Link Status Out of Service from its peer
since it received Link Status Alignment.
then M2PA SHALL send Link In Service to its MTP3.
If there is a local processor outage condition during the alignment
procedure, M2PA sends Link Status Processor Outage to its peer. When
the local processor outage condition ends, then M2PA SHALL send Link
Status Processor Outage Ended to its peer. M2PA SHALL attempt to
complete the alignment procedure during the local processor outage
condition.
If M2PA receives a Link Status Processor Outage during alignment, and
M2PA had received a Start Request from its MTP3, M2PA SHALL report
Remote Processor Outage to MTP3. M2PA SHALL attempt to complete the
alignment procedure during the remote processor outage condition.
If M2PA receives a Stop command from its MTP3 during alignment, M2PA
SHALL send Link Status Out of Service to its peer, terminate the
alignment procedure, and return to the Out of Service state.
Anomalous messages received during alignment SHOULD be
discarded. Examples include:
(a) User Data received before proving begins.
(b) Link Status Alignment received before or during proving.
Recommended values:
T1 Ready - Range: 40-50 seconds. Default: 45 seconds.
T2 Not Aligned - Range: 5-150 seconds. Default: 60 seconds.
T3 Aligned - Range: 1.0-1.5 seconds. Default: 1.0 seconds.
T4 Normal - Range: 7.5-9.5 seconds. Default: 8 seconds.
T4 Emergency - Range: 400-600 milliseconds.
Default: 500 milliseconds.
Proving_Interval - implementation dependent. The Link Status Ready message replaces the FISU of MTP2 that is sent
at the end of the proving period. The Link Status Ready message is
used to verify that both ends have completed proving. When M2PA starts
timer T1, it SHALL send a Link Status Ready message to its peer in the
case where MTP2 would send a FISU after proving is complete. M2PA MAY
send additional Link Status Ready messages while timer T1 is running.
4.1.4 Processor Outage 4.1.4 Processor Outage
A processor outage occurs when M2PA cannot transfer messages because The Link Status Processor Outage message replaces the SIPO message of
of a condition at a higher layer than M2PA. MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists. When the condition
When M2PA detects a local processor outage, it sends a Link Status ends, M2PA SHALL send a Link Status Processor Recovered message to its
message to its peer with status Processor Outage. M2PA SHALL also peer.
cease sending User Data messages to SCTP for transmission. M2PA SHALL
stop acknowledging received User Data messages.
M2PA MAY send additional Link Status Processor Outage messages as long While in a local processor outage condition:
as there is a local processor outage and the link is in service. If
the link is out of service, M2PA SHOULD locally mark that it is in
local processor outage.
The peer M2PA, upon receiving the Link Status Processor Outage (a) Any User Data messages received from the peer MUST NOT be
message, SHALL report Remote Processor Outage to its MTP3. The peer acknowledged and MUST be buffered.
M2PA ceases sending User Data messages. M2PA stops the Remote
Congestion timer T6 (see section 4.1.5 Level 2 Flow Control) if it is
running, and timer T7, if it is running.
MTP3 may send a Flush Buffers or Continue command to M2PA as part of (b) M2PA SHOULD continue to acknowledge User Data messages received
its processor outage procedure (See section 4.2.4 Flush Buffers and and accepted by MTP3 before the local processor outage.
Continue). The use of Flush Buffers and Continue is specified in Q.703
[Q.703] and T1.111.3 [T1.111].
Alternatively, MTP3 may perform data retrieval as part of a changeover (c) M2PA SHOULD continue running the T7 timer for messages sent
procedure. before the local processor outage.
When the processor outage ceases, MTP3 sends a Local Processor While there is a remote processor outage condition:
Recovered indication to M2PA. The local M2PA notifies its peer by
sending a Link Status message with status Processor Outage Ended. The
local M2PA SHALL resume receiving and transmitting messages.
If the peer is in the IN SERVICE state, it uses the Remote Processor (a) Any User Data messages received from the peer after the Link
Recovered Indication to notify its MTP3 that the remote processor Status Processor Outage MUST NOT be acknowledged and MUST be
outage condition has ceased. buffered.
4.1.5 Level 2 Flow Control (b) M2PA SHOULD continue to acknowledge User Data messages received
and accepted by MTP3 before the remote processor outage.
The determination of receive congestion in M2PA is implementation In other respects, M2PA SHOULD follow the same procedures as MTP2 in
dependent. processor outage.
If M2PA determines that it is in receive congestion for an 4.1.5 Level 2 Flow Control
association, M2PA SHALL send a Link Status Busy message to its peer on
that association. M2PA SHALL continue to acknowledge incoming
messages.
M2PA MAY send additional Link Status Busy messages as long as it is in The Link Status Busy message replaces the SIB message of MTP2. The
receive congestion. message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link
Status Busy message to its peer at the beginning of a receive
congestion condition where MTP2 would send SIB. M2PA MAY send
additional Link Status Processor Outage messages as long as that
condition persists. When the condition ends, M2PA SHALL send a Link
Status Busy Ended message to its peer.
M2PA SHALL continue transmitting messages while it is in receive M2PA SHALL continue transmitting and acknowledging messages while it
congestion. is in receive congestion.
When the peer M2PA receives the first Link Status Busy message, it When the peer M2PA receives the first Link Status Busy message, it
SHALL start the Remote Congestion timer T6. Additional Link Status SHALL start the Remote Congestion timer T6. Additional Link Status
Busy messages received while T6 is running do not cause T6 to be Busy messages received while T6 is running do not cause T6 to be
reset. reset.
If timer T6 expires, M2PA SHALL take the link out of service. M2PA The peer M2PA SHOULD continue transmitting and acknowledging messages
sends a Link Status Out of Service message to its peer, and goes to while its T6 timer is running, i.e., while the other end is Busy.
the Out of Service state.
The peer M2PA SHOULD continue transmitting messages to SCTP while its 4.1.6 Link Out of Service
T6 timer is running, i.e., while the other end is Busy.
The peer M2PA SHALL NOT fail the link due to expiration of timer T7 The Link Status Out of Service message replaces the SIOS message of
excessive delay of acknowledgement (see section 4.2.1 Sending and MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
receiving messages) while its T6 timer is running, i.e., while the continuously. M2PA SHALL send a Link Status Out of Service message to
other end is Busy.
If M2PA is no longer in receive congestion for the association, M2PA its peer at the beginning of a condition where MTP2 would send
SHALL send a Link Status Busy Ended message to its peer on that SIOS. M2PA MAY send additional Link Status Out of Service messages as
association. long as that condition persists.
When the peer M2PA receives the Link Status Busy Ended message, it When M2PA places a link in the OUT OF SERVICE state, M2PA SHOULD NOT
SHALL stop timer T6. terminate the SCTP association.
Recommended values: 4.1.7 SCTP Association Problems
T6 Busy - Range: 1-6 seconds. Default: 4.5 seconds. The SCTP association for a link may become unusable, such as when one
of the following occurs:
4.1.6 Error Monitoring - SCTP sends a Send Failure notification to M2PA.
If M2PA loses the SCTP association for a link, M2PA SHALL report to - SCTP sends a Communication Lost notification to M2PA.
MTP3 that the link is out of service.
4.1.7 Transmission and Reception Priorities - SCTP sends a Communication Error notification to M2PA.
- The SCTP association is lost.
If the SCTP association for a link becomes unable to transmit or
receive messages, M2PA SHALL report to MTP3 that the link is out of
service and enter the OUT OF SERVICE state.
4.1.8 Transmission and Reception Priorities
In MTP, Link Status messages have priority over User Data messages In MTP, Link Status messages have priority over User Data messages
([Q.703], section 11.2). To achieve this in M2PA, M2PA SHALL send ([Q.703], section 11.2). To achieve this in M2PA, M2PA SHALL send
Link Status and User Data messages on separate streams in its SCTP Link Status and User Data messages on separate streams in its SCTP
association. M2PA SHALL send all messages using the ordered delivery association. M2PA SHALL send all messages using the ordered delivery
option of SCTP. option of SCTP.
M2PA SHOULD give higher priority to Link Status messages than to User M2PA SHOULD give higher priority to Link Status messages than to User
Data messages when sending messages to SCTP. Data messages when sending messages to SCTP.
M2PA SHOULD give higher priority to reading the Link Status stream M2PA SHOULD give higher priority to reading the Link Status stream
than to reading the User Data stream. than to reading the User Data stream.
M2PA SHOULD give higher priority to receiving notifications from SCTP M2PA SHOULD give higher priority to receiving notifications from SCTP
than to reading either the Link Status stream or the User Data stream. than to reading either the Link Status stream or the User Data stream.
4.1.8 M2PA Version Control 4.1.9 M2PA Version Control
A node upgraded to a newer version of M2PA SHOULD support the older A node upgraded to a newer version of M2PA SHOULD support the older
versions used on other nodes with which it is communicating. If that versions used on other nodes with which it is communicating. If that
is the case, then alignment can proceed normally. is the case, then alignment can proceed normally.
In particular, it is recommended that for future modifications to this In particular, it is recommended that for future modifications to this
protocol: protocol:
- Any newer version SHOULD be able to process the messages from a - Any newer version SHOULD be able to process the messages from an
lower version. older version.
- A newer version of M2PA SHOULD refrain from sending messages to an - A newer version of M2PA SHOULD refrain from sending messages to an
older version of M2PA messages that the older version cannot older version of M2PA messages that the older version cannot
process. process.
- If an older version of M2PA receives a message that it cannot - If an older version of M2PA receives a message that it cannot
process, it SHOULD discard the message. process, it SHOULD discard the message.
- In cases where different processing is done in two versions for the - In cases where different processing is done in two versions for the
same format of a message, then the newer version SHOULD contain same format of a message, then the newer version SHOULD contain
procedures to recognize this and handle it appropriately. procedures to recognize this and handle it appropriately.
In case a newer version of M2PA is incompatible with an older version, In case a newer version of M2PA is incompatible with an older version,
the newer version SHOULD recognize this and prevent the alignment of the newer version SHOULD recognize this and prevent the alignment of
the link. If a Link Status Alignment message with an unsupported the link. If a Link Status Alignment message with an unsupported
version is received by the newer version, the receiving end's M2PA version is received by the newer version, the receiving end's M2PA
SHALL NOT complete the alignment procedure. SHOULD reply with a Link Status Out of Service message and not
complete the alignment procedure.
4.2 Procedures to Support the MTP3/MTP2 Interface 4.2 Procedures to Support the MTP3/MTP2 Interface
4.2.1 Sending and receiving messages 4.2.1 Sending and receiving messages
When MTP3 sends a message for transmission to M2PA, M2PA passes the When MTP3 sends a message for transmission to M2PA, M2PA passes the
corresponding M2PA message to SCTP using the SEND primitive. corresponding M2PA message to SCTP using the SEND primitive.
M2PA Link Status messages are passed to SCTP using the SEND primitive. User Data messages SHALL be sent via stream 1 of the association.
Link Status and User Data messages SHALL be sent via SCTP on separate M2PA Link Status messages are passed to SCTP using the SEND primitive.
streams.
When M2PA receives a User Data message from SCTP, M2PA passes the Link Status messages SHALL be sent via stream 0 of the association.
message to MTP3.
If M2PA receives a message from SCTP with an invalid Message Class or If M2PA receives a message from SCTP with an invalid Message Class or
unsupported Message Type in the Common Message Header, M2PA SHALL unsupported Message Type in the Common Message Header, M2PA SHALL
discard the message. discard the message.
The first User Data message sent after the link is placed in service
is given a Forward Sequence Number (FSN) of 1.
The Forward Sequence Number of the header is incremented by 1 for each
User Data message sent (provided that the message contains a data
payload). When the FSN reaches the maximum value, the next FSN is 0.
For message types other than User Data, the Forward Sequence Number is For message types other than User Data, the Forward Sequence Number is
set to the FSN of the last User Data message sent. set to the FSN of the last User Data message sent.
The Backward Sequence Number is set to the FSN of the last User Data
message M2PA received from its peer. This serves as an M2PA-level
acknowledgement of the message. After the link is placed in service
and before a User Data message has been received, the BSN is set to 0.
When M2PA receives a User Data message with Backward Sequence Number
equal to 'n', it may remove all messages with Forward Sequence Number
<= n from its queue.
If M2PA receives a User Data message with an FSN that is out of order, If M2PA receives a User Data message with an FSN that is out of order,
M2PA SHALL take the link out of service. M2PA SHALL place the link out of service (see section 4.1.6 Link Out
of Service).
M2PA SHOULD follow the criterion of Q.703 [Q.703], section 5.3.1 for
incorrect BSNs: If any two BSNs in three consecutively received User
Data messages are not the same as the previous one or any of the FSNs
of the User Data messages in the M2PA transmit buffer at the time they
are received, then MTP3 SHOULD be informed that the link is faulty.
M2PA SHOULD ignore the FSN and BSN contained in a Link Status message. M2PA SHOULD ignore the FSN and BSN contained in a Link Status message.
Note: In all calculations involving FSN and BSN, the programmer should Note: In all calculations involving FSN and BSN, the programmer should
be aware that the value wraps around to 0 after reaching its maximum be aware that the value wraps around to 0 after reaching its maximum
value. value.
If there is no other User Data message to be sent when there is a If there is no other User Data message to be sent when there is a
message to acknowledge, M2PA may send a User Data message with no data message to acknowledge, M2PA SHOULD send a User Data message with no
payload. The FSN for this empty User Data message is not data payload. The FSN for this empty User Data message is not
incremented. It MUST contain the same FSN as the most recently sent incremented. It MUST contain the same FSN as the most recently sent
User Data message containing Data. User Data message containing Data. This message SHOULD be sent
promptly in order to prevent poor SS7 performance.
If M2PA receives an empty User Data message, it SHALL NOT send an If M2PA receives an empty User Data message, it SHALL NOT send an
acknowledgement of that message. acknowledgement of that message.
Note that there is no reason to place empty User Data messages in the Note that there is no reason to place empty User Data messages in the
M2PA retransmit buffer, since the empty messages are not retransmitted M2PA retransmit buffer, since the empty messages are not retrieved for
and timer T7 (below) does not apply to them. changeover and timer T7 does not apply to them.
Note that since SCTP provides reliable delivery and ordered delivery Note that since SCTP provides reliable delivery and ordered delivery
within the stream, M2PA does not perform retransmissions. within the stream, M2PA does not perform
retransmissions. Nevertheless, M2PA SHALL retain transmitted User Data
Timer T7 provides an indication of excessive delay of messages in a retransmit queue until they are acknowledged. These
acknowledgement. If the following conditions are true: messages are needed in case MTP3 performs data retrieval as part of a
changeover procedure.
(a) There is at least one message in the M2PA retransmit buffer.
(b) The remote M2PA is not in a Busy condition (i.e., the local
timer T6 is not running).
(c) There is a message in the M2PA retransmit buffer that has not
received an acknowledgement in the span of T7 since its last
transmission.
then M2PA SHOULD take the link out of service.
Recommended values:
T7 Acknowledgement - Range: 0.5-2 seconds. Default: 1.0 seconds.
4.2.2 Link activation and restoration
When MTP3 requests that M2PA activate or restore a link by a Start
Request, M2PA SHALL follow the alignment procedure in section 4.1.3.
4.2.3 Link deactivation
When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA
SHALL send a Link Status Out of Service message to its peer.
The peer M2PA, upon receiving Link Status Out of Service, SHALL notify
its upper layer MTP3 that the link is out of service.
4.2.4 Flush Buffers and Continue
The Flush Buffers and Continue commands allow M2PA to resume normal
operations (i.e., transmission of messages to SCTP and receiving
messages from SCTP) after a processor outage (local and/or remote)
ceases.
If M2PA receives a Flush Buffers command from MTP3, M2PA:
(a) SHALL NOT transmit any messages to SCTP that are currently
waiting to be transmitted to SCTP. These messages SHALL be
discarded.
(b) SHALL discard all messages currently waiting to be passed Because propagation delays in IP networks are more variable than in
to MTP3. traditional SS7 networks, a single T7 timer (excessive delay of
acknowledgement) is inadequate. A T7 timer SHALL be started for each
message in the M2PA retransmit buffer.
4.2.5 MTP3 Signaling Link Congestion 4.2.2 MTP3 Signaling Link Congestion
M2PA SHALL detect transmit congestion in its buffers according to the M2PA SHALL detect transmit congestion in its buffers according to the
requirements for signaling link transmit congestion in Q.704 [Q.704], requirements for signaling link transmit congestion in MTP3, e.g.,
section 3.8. Q.704 [Q.704], section 3.8.
M2PA SHALL use the Congestion Indication primitive to notify its upper
layer MTP3 of changes in the signaling link congestion status and the
signaling link discard status. For national networks with multiple
congestion threshold levels, M2PA SHALL notify MTP3 of the congestion
and discard status levels.
4.2.6 Changeover 4.2.3 Changeover
The objective of the changeover is to ensure that signaling traffic The objective of the changeover is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the carried by the unavailable signaling link is diverted to the
alternative signaling link(s) as quickly as possible while avoiding alternative signaling link(s) as quickly as possible while avoiding
message loss, duplication, or mis-sequencing. For this purpose, the message loss, duplication, or mis-sequencing. For this purpose, the
changeover procedure includes data retrieval, which is performed changeover procedure includes data retrieval, which is performed
before opening the alternative signaling links to the diverted before opening the alternative signaling links to the diverted
traffic. Data retrieval consists of these steps: traffic. Data retrieval consists of these steps:
(1) buffer updating, i.e., identifying all those User Data (1) buffer updating, i.e., identifying all those User Data
skipping to change at page 36, line 5 skipping to change at page 31, line 26
[T1.111] are required. The BSN is placed in the XCO/XCA message as [T1.111] are required. The BSN is placed in the XCO/XCA message as
explained in [Q.2210] and [T1.111]. explained in [Q.2210] and [T1.111].
Also, the following MTP3/MTP2 primitives MUST use the larger sequence Also, the following MTP3/MTP2 primitives MUST use the larger sequence
numbers: numbers:
- BSNT Confirmation - BSNT Confirmation
- Retrieval Request and FSNC - Retrieval Request and FSNC
For data retrieval, MTP3 requests the Backward Sequence Number to be
Transmitted (BSNT) from M2PA through the Retrieve BSNT request. M2PA
determines the Forward Sequence Number of the last User Data message
received from the peer. This value is the BSNT. M2PA sends the BSNT
value to MTP3 in the BSNT confirmation. In the same way, the remote
end also detects its BSNT. The MTP3 layers exchange BSNT values
through the XCO and XCA messages. The BSNT received from the other end
is called the FSNC. When MTP3 receives the FSNC from the other end,
MTP3 retrieves all the unsent and unacknowledged messages starting
with sequence number (FSNC + 1). This is accomplished through a
Retrieval Request and FSNC request. After all the messages are sent
from M2PA to MTP3, M2PA sends a Retrieval Complete indication to MTP3.
If there are any messages on the M2PA or SCTP receive queues that have
not been acknowledged by M2PA, M2PA SHOULD discard these messages. The
peer will retransmit them on an alternate link. Any messages
acknowledged by M2PA MUST NOT be discarded. These messages MUST be
delivered to MTP3.
If M2PA receives a Retrieve BSNT request from MTP3, M2PA SHALL respond
with the BSNT confirmation. The BSNT value is the Forward Sequence
Number of the last User Data message received from the peer.
If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA
SHALL retrieve from its buffers in order and deliver to MTP3: SHALL retrieve from its buffers and deliver to MTP3 in order:
(a) any transmitted User Data messages beginning with the first (a) any transmitted User Data messages beginning with the first
unacknowledged message with FSN greater than FSNC. unacknowledged message with FSN greater than FSNC.
(b) any untransmitted User Data messages. (b) any untransmitted User Data messages.
Then M2PA SHALL send the Retrieval Complete indication to MTP3.
For emergency changeover, MTP3 retrieves only the unsent messages for For emergency changeover, MTP3 retrieves only the unsent messages for
transmission on the alternate link(s). If M2PA receives a Retrieval transmission on the alternate link(s). If M2PA receives a Retrieval
Request and FSNC request with no FSNC value, or with an invalid FSNC, Request and FSNC request with no FSNC value, or with an invalid FSNC,
then M2PA SHALL retrieve from its buffers in order and deliver to then M2PA SHALL retrieve from its buffers and deliver to MTP3 in
MTP3: order:
(a) any untransmitted User Data messages. (a) any untransmitted User Data messages.
Then M2PA SHALL send the Retrieval Complete indication to MTP3.
Note: For the Japanese version of MTP defined in [JT-Q704], MTP3 Note: For the Japanese version of MTP defined in [JT-Q704], MTP3
retrieves both unsent and unacknowleged messages for transmission on retrieves both unsent and unacknowleged messages for transmission on
the alternate link(s). In this version of MTP, if M2PA receives a the alternate link(s). In this version of MTP, if M2PA receives a
Retrieval Request and FSNC request with no FSNC value, or with an Retrieval Request and FSNC request with no FSNC value, or with an
invalid FSNC, then M2PA SHALL retrieve from its buffers in order and invalid FSNC, then M2PA SHALL retrieve from its buffers and deliver to
deliver to MTP3: MTP3 in order:
(a) any transmitted but unacknowledged User Data messages. (a) any transmitted but unacknowledged User Data messages.
(b) any untransmitted User Data messages. (b) any untransmitted User Data messages.
Then M2PA SHALL send the Retrieval Complete indication to MTP3. 4.2.3.1 Multiple User Data Streams and Changeover
4.2.6.1 Multiple User Data Streams and Changeover
The changeover procedure makes it problematic for M2PA to have The changeover procedure makes it problematic for M2PA to have
multiple User Data streams in one direction for a link. Buffer multiple User Data streams in one direction for a link. Buffer
updating would have to be done for each User Data stream separately to updating would have to be done for each User Data stream separately to
avoid duplication or loss of messages. But MTP3 provides for only one avoid duplication or loss of messages. But MTP3 provides for only one
XCO/XCA message for sending the last-received sequence number. XCO/XCA message for sending the last-received sequence number.
Even with sequence numbering of User Data messages at the M2PA layer, Even with sequence numbering of User Data messages at the M2PA layer,
it is necessary to perform buffer updating on each stream. Since the it is necessary to perform buffer updating on each stream. Since the
M2PA messages would be delivered over multiple streams, there could be M2PA messages would be delivered over multiple streams, there could be
skipping to change at page 39, line 20 skipping to change at page 34, line 20
from SCTP are used to generate a meaningful message to MTP3. from SCTP are used to generate a meaningful message to MTP3.
Note that throughout this section, the primitives between MTP3 and Note that throughout this section, the primitives between MTP3 and
M2PA are named using the MTP terminology [Q.700] [Q.701] [Q.702] M2PA are named using the MTP terminology [Q.700] [Q.701] [Q.702]
[Q.703] [Q.704] [Q.705]. Communications between M2PA and SCTP are [Q.703] [Q.704] [Q.705]. Communications between M2PA and SCTP are
named using SCTP terminology. named using SCTP terminology.
5.1 Link Initialization (Alignment) 5.1 Link Initialization (Alignment)
An example of the message flow to bring an SS7 link in service is An example of the message flow to bring an SS7 link in service is
shown in Figures 12 and 13. Alignment is done by both ends of the shown in Figures 11 and 12. Alignment is done by both ends of the
link. To simplify the diagram, alignment is shown on one end link. To simplify the diagram, alignment is shown on one end
only. Some messages from the remote end are not shown. It is assumed only. Some messages from the remote end are not shown. It is assumed
in this example that SCTP has been initialized. in this example that SCTP has been initialized.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Associate . . . . . Associate . . . .
. ------------> . . . . ------------> . . .
. . . . . . . . . . . .
skipping to change at page 40, line 37 skipping to change at page 35, line 37
. . . . . . . . . . . .
. Link Status Alignment . . . . Link Status Alignment . . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
. Start timer T2 . . . . Start timer T2 . . .
. . . . . . . . . . . .
. . . Link Status Alignment . . . . Link Status Alignment .
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
. Stop timer T2 . . . . Stop timer T2 . . .
. Start timer T4 . . .
. . . . . . . . . . . .
Proving period begins. Proving period begins.
Figure 12. Example: Link Initialization - Alignment Figure 11. Example: Link Initialization - Alignment
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Start timers T3, T4 . . .
. . . . . .
. . . Link Status Proving .
. <------------------------------------ .
. . . . . .
. Stop timer T3 . . .
. . . . . .
. Link Status Proving . . . . Link Status Proving . . .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
. Timer T4 expires . . . . Timer T4 expires . . .
. . . . . . . . . . . .
skipping to change at page 41, line 39 skipping to change at page 36, line 46
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
. Stop timer T1 . . . . Stop timer T1 . . .
. . . . . . . . . . . .
In Service . . In Service In Service . . In Service
<------------ . . ------------> <------------ . . ------------>
. . . . . . . . . . . .
MTP3 MAY begin sending data messages. MTP3 MAY begin sending data messages.
Figure 13. Example: Link Initialization - Proving Figure 12. Example: Link Initialization - Proving
5.2 Message Transmission and Reception 5.2 Message Transmission and Reception
Messages are transmitted using the Data Request primitive from MTP3 to Messages are transmitted using the Data Request primitive from MTP3 to
M2PA. Figure 14 shows the case where the Link is In Service. The M2PA. Figure 13 shows the case where the Link is In Service. The
message is passed from MTP3 of the source to MTP3 of the destination. message is passed from MTP3 of the source to MTP3 of the destination.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
Message for . . . . Message for . . . .
transmission . . . . transmission . . . .
------------> . . . . ------------> . . . .
. . . . . . . . . . . .
. Send . . . . . Send . . . .
skipping to change at page 42, line 31 skipping to change at page 37, line 31
. . . . . . . . . . . .
. . (SCTP sends message) . . . . (SCTP sends message) . .
. . . . . . . . . . . .
. . . Receive . . . . Receive .
. . . ------------> . . . . ------------> .
. . . . . . . . . . . .
. . . . Received message . . . . Received message
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
Figure 14. Example: Link Initialization - In Service Figure 13. Example: Link Initialization - In Service
5.3 Link Status Indication 5.3 Link Status Indication
An example of a Link Status Indication is shown in Figure 15. If SCTP An example of a Link Status Indication is shown in Figure 14. If SCTP
sends a Communication Lost primitive to M2PA, M2PA notifies MTP3 that sends a Communication Lost primitive to M2PA, M2PA notifies MTP3 that
the link is out of service. MTP3 responds in its usual way. the link is out of service. MTP3 responds in its usual way.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Communication Lost . . . . Communication Lost . . .
. <------------ . . . . <------------ . . .
. . . . . . . . . . . .
Out of Service . . . . Out of Service . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 15. Example: Link Status Indication Figure 14. Example: Link Status Indication
5.4 Link Status Message (Processor Outage) 5.4 Link Status Message (Processor Outage)
Figure 16 shows how M2PA responds to a local processor outage. M2PA Figure 15 shows how M2PA responds to a local processor outage. M2PA
sends a Link Status message to its peer. The peer M2PA notifies MTP3 sends a Link Status message to its peer. The peer M2PA notifies MTP3
of the outage. MTP3 can then follow the processor outage procedures in of the outage. MTP3 can then follow the processor outage procedures in
[Q.703]. [Q.703].
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. M2PA detects . . . . . M2PA detects . . . .
. Local Processor . . . . . Local Processor . . . .
. Outage . . . . . Outage . . . .
skipping to change at page 43, line 47 skipping to change at page 38, line 47
. . (SCTP sends message) . . . . (SCTP sends message) . .
. . . . . . . . . . . .
. . . Receive . . . . . Receive . .
. . . ------------> . . . . ------------> .
. . . . . . . . . . . .
. . . . Remote Processor . . . . Remote Processor
. . . . Outage Ceases . . . . Outage Ceases
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
Figure 16. Example: Link Status Message - Processor Outage Figure 15. Example: Link Status Message - Processor Outage
5.5 Level 2 Flow Control 5.5 Level 2 Flow Control
Figures 17 and 18 illustrate the Level 2 Flow Control procedure. In Figures 16 and 17 illustrate the Level 2 Flow Control procedure. In
Figure 17, congestion ceases before timer T6 expires. Figure 18 shows Figure 16, congestion ceases before timer T6 expires. Figure 17 shows
the case where T6 expires. the case where T6 expires.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . determination of M2PA . .
. receive congestion onset . . . receive congestion onset . .
. . . . . . . . . . . .
. Link Status Busy . . . . Link Status Busy . . .
skipping to change at page 44, line 35 skipping to change at page 39, line 35
. determination of M2PA . . . determination of M2PA . .
. receive congestion abatement . . . receive congestion abatement . .
. . . . . . . . . . . .
. Link Status Busy Ended . . . . Link Status Busy Ended . . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
. . . . Stop . . . . . Stop .
. . . . Timer T6 . . . . . Timer T6 .
. . . . . . . . . . . .
Figure 17. Example: Level 2 Flow Control - Congestion Ceases Figure 16. Example: Level 2 Flow Control - Congestion Ceases
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . determination of M2PA . .
. receive congestion onset . . . receive congestion onset . .
. . . . . . . . . . . .
. Link Status Busy . . . . Link Status Busy . . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
skipping to change at page 45, line 28 skipping to change at page 40, line 28
. . . . Timer T6 . . . . . Timer T6 .
. . . . Expires . . . . . Expires .
. . . . . . . . . . . .
. . Link Status Out of Service . . . Link Status Out of Service .
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
. . . . Out of Service . . . . Out of Service
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
Figure 18. Example: Level 2 Flow Control - Timer T6 Expires Figure 17. Example: Level 2 Flow Control - Timer T6 Expires
5.6 MTP3 Signaling Link Congestion 5.6 MTP3 Signaling Link Congestion
In Figure 19, M2PA notifies MTP3 of congestion onset and In Figure 18, M2PA notifies MTP3 of congestion onset and
abatement. The notification includes the congestion level, if there abatement. The notification includes the congestion level, if there
are levels of congestion defined. are levels of congestion defined.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . . determination of M2PA . . .
. transmit congestion . . . . transmit congestion . . .
. onset (level) . . . . onset (level) . . .
skipping to change at page 46, line 33 skipping to change at page 41, line 33
. Implementation dependent . . . Implementation dependent . .
. determination of M2PA . . . . determination of M2PA . . .
. transmit congestion . . . . transmit congestion . . .
. abatement (level) . . . . abatement (level) . . .
. . . . . . . . . . . .
Congestion Indication . . . . Congestion Indication . . . .
(level) . . . . . (level) . . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 19. Example: MTP3 Signalling Link Congestion Figure 18. Example: MTP3 Signalling Link Congestion
5.7 Link Deactivation 5.7 Link Deactivation
Figure 20 shows an example of link deactivation. MTP3 can request that Figure 19 shows an example of link deactivation. MTP3 can request that
a link be taken out of service. a link be taken out of service.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
Stop . . . . . Stop . . . . .
------------> . . . . ------------> . . . .
. . . . . . . . . . . .
. Link Status Out of Service . . . Link Status Out of Service . .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
Out of Service . . . . Out of Service . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 20. Example: Link Deactivation Figure 19. Example: Link Deactivation
5.8 Link Changeover 5.8 Link Changeover
In Figure 21, MTP3 performs a changeover because the link went out of In Figure 20, MTP3 performs a changeover because the link went out of
service. MTP3 selects a different link to retransmit the service. MTP3 selects a different link to retransmit the
unacknowledged and unsent messages. unacknowledged and unsent messages.
Note that in this example, the sequence numbers and messages requested
by MTP3 are sent from SCTP to M2PA in the Communication Lost
primitive. In general, the retrieval of sequence numbers and messages
is implementation dependent.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. Communication Lost . . . . Communication Lost . . .
. <------------ . . . . <------------ . . .
. . . . . . . . . . . .
Out of Service . . . . Out of Service . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Retrieve BSNT . . . . Retrieve BSNT . . . .
skipping to change at page 49, line 47 skipping to change at page 43, line 53
<------------ . . . . <------------ . . . .
. : . . . . . . : . . . . .
. : . . . . . . : . . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Retrieval Complete . . . . Retrieval Complete . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Send messages on another link. Send messages on another link.
Figure 21. Example: Link Changeover Figure 20. Example: Link Changeover
6. Security 6. Security
M2PA is designed to carry signaling messages for telephony M2PA is designed to carry signaling messages for telephony
services. As such, M2PA MUST involve the security needs of several services. As such, M2PA MUST involve the security needs of several
parties: the end users of the services, the network providers, and the parties:
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
There is no quick-fix, one-size-fits-all solution for security. As a
transport protocol, M2PA has the following security objectives:
- Availability of reliable and timely user data transport.
- Integrity of user data transport. - the end users of the services
- Confidentiality of user data. - the network providers
M2PA runs on top of SCTP. SCTP [RFC2960] provides certain transport - the applications involved
related security features, such as:
- Blind Denial of Service Attacks Additional requirements MAY come from local regulation.
- Flooding While these parties may have some overlapping security needs, their
needs may not be identical. Any security solution SHOULD fulfill all
of the different parties' needs.
- Masquerade 6.1 Security Requirements
- Improper Monopolization of Services Consult [Security] for a discussion of security requirements and for
guidance on the use of security protocols.
When M2PA is running in professionally managed corporate or service When M2PA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site Security includes an appropriate security policy framework. The "Site Security
Handbook" [RFC2196] SHOULD be consulted for guidance. Handbook" [RFC2196] SHOULD be consulted for guidance.
When the network in which M2PA runs involves more than one party
(e.g., a non-private network), it MAY NOT be reasonable to expect that
all parties have implemented security in a sufficient manner. In such
a case, it is recommended that IPSEC be used to ensure confidentiality
of user payload. Consult [RFC2401] for more information on configuring
IPSEC services.
6.2 Protecting Confidentiality 6.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality MAY Particularly for wireless users, the requirement for confidentiality
include the masking of IP addresses and ports. In this case MAY include the masking of IP addresses and ports. In this case
application-level encryption is not sufficient. IPSEC ESP SHOULD be application-level encryption is not sufficient. IPSec ESP SHOULD be
used instead. Regardless of which level performs the encryption, the used instead [RFC2401]. Regardless of which level performs the
IPSEC ISAKMP service SHOULD be used for key management. encryption, the IPSec ISAKMP service SHOULD be used for key
management.
7. IANA Considerations 7. IANA Considerations
7.1 SCTP Payload Protocol Identifier 7.1 SCTP Payload Protocol Identifier
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA The SCTP (and TCP) Registered User Port Number Assignment for M2PA
is 3565. is 3565.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is SCTP Payload Data chunk is
M2PA 5 M2PA 5
The SCTP Payload Protocol Identifier is included in each SCTP Data The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but may be used by Protocol Identifier is not directly used by SCTP but may be used by
skipping to change at page 53, line 9 skipping to change at page 46, line 46
(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 multiple instances of this parameter type may be found within
the same message type. the same message type.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the following for their valuable The authors would like to thank the following for their valuable
comments and suggestions: Brian Tatum, Jeff Copley, Monique Bernard, comments and suggestions: Brian Tatum, Jeff Copley, Monique Bernard,
Wayne Davis, Cliff Thomas, Ian Rytina, Al Varney. Wayne Davis, Malleswar Kalla, Cliff Thomas, Ian Rytina, Greg
Sidebottom, Al Varney, Jeff Craig, Andrew Booth.
9. References 9. References
9.1 Normative
[JT-Q704] [JT-Q704]
TTC, "Message Transfer Part Signalling Network Functions," TTC TTC, "Message Transfer Part Signalling Network Functions," TTC
Standard JT-Q704, Telecommunication Technology Committee (TTC) Standard JT-Q704, Telecommunication Technology Committee (TTC)
(April 28, 1992). (April 28, 1992).
[M2UA]
K. Morneault, et. al., "Signaling System 7 (SS7) Message
Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
Internet Engineering Task Force - Signalling Transport Working
Group (September, 2002).
[Q.700]
ITU, "Introduction to CCITT Signalling System No. 7," ITU-T
Recommendation Q.700, ITU-T Telecommunication Standardization
Sector of ITU (March 1993).
[Q.701]
ITU, "Functional Description of the Message Transfer Part (MTP)
of Signalling System No. 7," ITU-T Recommendation Q.701, ITU-T
Telecommunication Standardization Sector of ITU (March 1993).
[Q.702]
ITU, "Signalling Data Link," ITU-T Recommendation Q.702, ITU-T
Telecommunication Standardization Sector of ITU (March 1993).
[Q.703] [Q.703]
ITU, "Signalling System No. 7 - Signalling Link," ITU-T ITU, "Signalling System No. 7 - Signalling Link," ITU-T
Recommendation Q.703, ITU-T Telecommunication Standardization Recommendation Q.703, ITU-T Telecommunication Standardization
Sector of ITU (March 1993). Sector of ITU (March 1993).
[Q.704] [Q.704]
ITU, "Message Transfer Part - Signalling Network Functions and ITU, "Message Transfer Part - Signalling Network Functions and
Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication
Standardization Sector of ITU (March 1993). Standardization Sector of ITU (March 1993).
[Q.705]
ITU, "Signalling System No. 7 - Signalling Network Structure,"
ITU-T Recommendation Q.705, ITU-T Telecommunication
Standardization Sector of ITU (March 1993).
[Q.2140] [Q.2140]
ITU, "B-ISDN ATM Adaptation Layer - Service Specific ITU, "B-ISDN ATM Adaptation Layer - Service Specific
Coordination Function for Signalling at the Network Node Coordination Function for Signalling at the Network Node
Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T
Telecommunication Standardization Sector of ITU (February Telecommunication Standardization Sector of ITU (February
1996). 1996).
[Q.2210] [Q.2210]
ITU, "Message Transfer Part Level 3 Functions and Messages ITU, "Message Transfer Part Level 3 Functions and Messages
Using the Services of ITU-T Recommendation Q.2140," ITU-T Using the Services of ITU-T Recommendation Q.2140," ITU-T
skipping to change at page 54, line 42 skipping to change at page 48, line 10
[RFC2401] [RFC2401]
S. Kent, R. Atkinson, "Security Architecture for the Internet S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol," RFC 2401, Internet Engineering Task Force (November Protocol," RFC 2401, Internet Engineering Task Force (November
1998). 1998).
[RFC2434] [RFC2434]
T. Narten, H. T. Alvestrand, "Guidelines for Writing an IANA T. Narten, H. T. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," BCP 26, RFC 2434, The Internet Considerations Section in RFCs," BCP 26, RFC 2434, The Internet
Society (October, 1998). Society (October, 1998).
[RFC2719]
L. Ong, et. al., "Framework Architecture for Signaling
Transport," RFC 2719, The Internet Society (October 1999).
[RFC2960] [RFC2960]
R. Stewart, et. al., "Stream Control Transmission Protocol R. Stewart, et. al., "Stream Control Transmission Protocol
(SCTP)," RFC 2960, The Internet Society (February 2000). (SCTP)," RFC 2960, The Internet Society (February 2000).
[RFC3309]
J. Stone, R. Stewart, and D. Otis, "Stream Control Transmission
Protocol (SCTP) Checksum Change," RFC 3309, The Internet
Society (September 2002).
[Security]
J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security
Considerations for SIGTRAN Protocols,"
draft-ietf-sigtran-security-02.txt (January 2003).
[T1.111] [T1.111]
ANSI, "American National Standard for Telecommunications - ANSI, "American National Standard for Telecommunications -
Signaling System Number 7 (SS7) - Message Transfer Part (MTP)," Signaling System Number 7 (SS7) - Message Transfer Part (MTP),"
ANSI T1.111-2000, American National Standards Institute (2000). ANSI T1.111-2000, American National Standards Institute (2000).
9.2 Informative
[M2UA]
K. Morneault, et. al., "Signaling System 7 (SS7) Message
Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
Internet Engineering Task Force - Signalling Transport Working
Group (September, 2002).
[Q.700]
ITU, "Introduction to CCITT Signalling System No. 7," ITU-T
Recommendation Q.700, ITU-T Telecommunication Standardization
Sector of ITU (March 1993).
[Q.701]
ITU, "Functional Description of the Message Transfer Part (MTP)
of Signalling System No. 7," ITU-T Recommendation Q.701, ITU-T
Telecommunication Standardization Sector of ITU (March 1993).
[Q.702]
ITU, "Signalling Data Link," ITU-T Recommendation Q.702, ITU-T
Telecommunication Standardization Sector of ITU (March 1993).
[Q.705]
ITU, "Signalling System No. 7 - Signalling Network Structure,"
ITU-T Recommendation Q.705, ITU-T Telecommunication
Standardization Sector of ITU (March 1993).
[RFC2719]
L. Ong, et. al., "Framework Architecture for Signaling
Transport," RFC 2719, The Internet Society (October 1999).
10. Author's Addresses 10. Author's Addresses
Tom George Tel: +1-972-519-3168 Tom George Tel: +1-972-519-3168
Alcatel USA, Inc. EMail: Tom.George@alcatel.com Alcatel EMail: Tom.George@alcatel.com
1000 Coit Road 3400 West Plano Parkway
Plano, TX 75075 Plano, TX 75075
USA USA
Brian Bidulock Tel +1-780-490-1141 Brian Bidulock Tel +1-780-490-1141
OpenSS7 Corporation EMail: bidulock@openss7.org OpenSS7 Corporation EMail: bidulock@openss7.org
1469 Jeffreys Crescent 1469 Jeffreys Crescent
Edmonton, AB T6L 6T1 Edmonton, AB T6L 6T1
Canada Canada
Ram Dantu, Ph.D. Tel: +1-214-291-1111 Ram Dantu, Ph.D. Tel: +1-214-291-1111
Netrake Corporation EMail: rdantu@netrake.com Netrake Corporation EMail: rdantu@netrake.com
3000 Technology Drive, Suite 100 3000 Technology Drive, Suite 100
Plano 75074 Plano 75074
USA USA
Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: kalla@research.telcordia.com
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA
Hanns Juergen Schwarzbauer Tel: +49-89-722-24236 Hanns Juergen Schwarzbauer Tel: +49-89-722-24236
SIEMENS AG HannsJuergen.Schwarzbauer@icn.siemens.de SIEMENS AG HannsJuergen.Schwarzbauer@icn.siemens.de
Hofmannstr. 51 Hofmannstr. 51
81359 Munich 81359 Munich
Germany Germany
Greg Sidebottom
Signatus Technologies EMail: greg@signatustechnologies.com
Kanata, Ontario
Canada
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
This Internet Draft expires July 2003. This Internet Draft expires October 2003.
 End of changes. 

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