draft-ietf-sigtran-m2pa-09.txt   draft-ietf-sigtran-m2pa-10.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
INTERNET-DRAFT Alcatel INTERNET-DRAFT Alcatel
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
Ram Dantu Ram Dantu
University of North Texas University of North Texas
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Expires December 2003 June 29, 2003 Expires April 2004 October 16, 2003
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-09.txt> <draft-ietf-sigtran-m2pa-10.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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.....................10
2. Protocol Elements........................................13 2. Protocol Elements........................................12
2.1 Common Message Header.................................13 2.1 Common Message Header.................................12
2.2 M2PA Header...........................................14 2.2 M2PA Header...........................................14
2.3 M2PA Messages.........................................15 2.3 M2PA Messages.........................................14
3. State Control............................................19 3. State Control............................................18
3.1 SCTP Association State Control........................19 3.1 SCTP Association State Control........................18
3.2 M2PA Link State Control...............................20 3.2 M2PA Link State Control...............................19
4. Procedures...............................................21 4. Procedures...............................................19
4.1 Procedures to Support MTP2 Features...................21 4.1 Procedures to Support MTP2 Features...................19
4.2 Procedures to Support the MTP3/MTP2 Interface.........31 4.2 Procedures to Support the MTP3/MTP2 Interface.........29
4.3 SCTP Considerations...................................34 4.3 SCTP Considerations...................................32
5. Examples of M2PA Procedures..............................35 5. Examples of M2PA Procedures..............................33
5.1 Link Initialization (Alignment).......................35 5.1 Link Initialization (Alignment).......................34
5.2 Message Transmission and Reception....................38 5.2 Message Transmission and Reception....................36
5.3 Link Status Indication................................38 5.3 Link Status Indication................................36
5.4 Link Status Message (Processor Outage)................39 5.4 Link Status Message (Processor Outage)................37
5.5 Level 2 Flow Control..................................40 5.5 Level 2 Flow Control..................................41
5.6 MTP3 Signaling Link Congestion........................42 5.6 MTP3 Signaling Link Congestion........................43
5.7 Link Deactivation.....................................43 5.7 Link Deactivation.....................................43
5.8 Link Changeover.......................................44 5.8 Link Changeover.......................................44
6. Security.................................................46 6. Security.................................................45
6.1 Security Requirements.................................46 6.1 Security Requirements.................................45
6.2 Protecting Confidentiality............................46 6.2 Protecting Confidentiality............................45
7. IANA Considerations......................................47 7. IANA Considerations......................................46
7.1 SCTP Payload Protocol Identifier......................47 7.1 SCTP Payload Protocol Identifier......................46
7.2 M2PA Protocol Extensions..............................47 7.2 M2PA Protocol Extensions..............................46
8. Acknowledgements.........................................49 8. Acknowledgements.........................................48
9. References...............................................49 9. References...............................................48
9.1 Normative..............................................49 9.1 Normative..............................................48
9.2 Informative............................................50 9.2 Informative............................................49
10. Author's Addresses.......................................51 10. Author's Addresses.......................................50
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 10, line 28 skipping to change at page 9, line 55
corresponding SCTP association. corresponding SCTP association.
1.7.3 SCTP Association 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, as well as Link Status messages
Data messages onto separate streams allows M2PA to prioritize the
messages in a manner similar to MTP2. that must remain in sequence with the User Data messages. Separating
the Link Status and User Data messages onto separate streams allows
M2PA to prioritize the messages in a manner similar to MTP2.
Notifications received from SCTP are processed by M2PA or translated Notifications received from SCTP are processed by M2PA or translated
into an appropriate notification to be sent to the upper layer MTP3. into an appropriate notification to be sent to the upper layer MTP3.
1.7.4 Retention of MTP3 in the SS7 Network 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
skipping to change at page 16, line 8 skipping to change at page 15, line 41
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Data / / Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data field contains the following fields of the MTP Message Signal The Data field contains the following fields of the MTP Message Signal
Unit (MSU): Unit (MSU):
- Length Indicator (LI), including the two undefined bits between - the Message Priority field (PRI)
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".
The Japanese TTC standard uses the PRI field as an MTP3 Message
Priority field [JT-Q703]. For versions of MTP that do not use these
two bits, the entire first octet of the Data field is spare.
M2PA SHALL NOT add padding to the MTP3 message. The format of the first octet of the Data field is:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PRI| spare | (followed by SIO, SIF)
+-+-+-+-+-+-+-+-+
PRI - Priority used only in national MTP defined in [JT-Q703].
Spare for other MTP versions.
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)
- Length Indicator (LI)
- Check bits (CK) - Check bits (CK)
The Data field SHALL be transmitted in the byte order as defined by The Data field SHALL be transmitted in the byte order as defined by
MTP3. MTP3.
It is not necessary to put the message length in the LI octet as in M2PA SHALL NOT add padding to the MTP3 message.
MTP2. The LI octet is included because the two spare bits in the LI
octet are used by MTP3 in at least one national version of SS7 to
carry MTP3 information. For example, the Japanese TTC standard uses
these spare bits as an MTP3 Message Priority field. See [JT-Q704],
section 14 "Common Characteristics of message signal unit formats",
section 14.2 (A) "Priority Indicator (PRI)". For versions of MTP that
do not use these two bits, the entire octet is spare.
Therefore in M2PA the format of the LI octet is:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PRI| spare | (followed by SIO, SIF)
+-+-+-+-+-+-+-+-+
PRI - Priority used only in national MTP defined in [JT-Q704].
Spare for other MTP versions.
Since the LI octet is not used for a message length, there is no need
to support the expanded LI field in Q.703 [Q.703] Annex A. Therefore
the LI field in M2PA is always one octet.
Note: In the SS7 Recommendations, the format of the messages and Note: In the SS7 Recommendations, the format of the messages and
fields within the messages are based on bit transmission order. In fields within the messages are based on bit transmission order. In
these recommendations the Least Significant Bit (LSB) of each field is these recommendations the Least Significant Bit (LSB) of each field is
positioned to the right. The received SS7 fields are populated octet positioned to the right. The received SS7 fields are populated octet
by octet as received into the 4-octet word as shown below. by octet as received into the 4-octet word as shown below.
As an example, in the ANSI MTP protocol, the Data field format is As an example, in the ANSI MTP protocol, the Data field format is
shown below: shown below:
skipping to change at page 21, line 12 skipping to change at page 19, line 27
These events affect the M2PA link state in a manner similar to MTP2. 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 Since M2PA provides MTP3 with an interface and functionality like
MTP2, its internal functioning is similar to that of MTP2. MTP2, its internal functioning is similar to that of MTP2.
Except as modified in this document, M2PA SHOULD follow the Except as modified in this document, M2PA SHOULD follow the
requirements of the applicable MTP2 specification. These may include requirements of the applicable MTP2 specification. These may include
[Q.703] or [T1.111]. [Q.703] or [T1.111]. The same standard MUST be followed on both ends
of the M2PA link.
When referring to MTP2 terminology in this document, the terminology When referring to MTP2 terminology in this document, the terminology
of [Q.703] is used. This does not imply that the requirements of of [Q.703] is used. This does not imply that the requirements of
[Q.703] are to be followed. [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
skipping to change at page 26, line 7 skipping to change at page 23, line 46
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | | | | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+ +=============+============+======+============+======+=====+
| 1 | IPA | P1 | IPB | PW | a | | 1 | IPA | P1 | IPB | PW | a |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
| 2 | IPA | PW | IPB | PW | b | | 2 | IPA | PW | IPB | PW | b |
+-------------+------------+------+------------+------+-----+ +-------------+------------+------+------------+------+-----+
The association SHALL contain two streams in each direction. Stream 0 The association SHALL contain two streams in each direction. Stream 0
is designated for Link Status messages. Stream 1 is designated for is designated for Link Status messages. Stream 1 is designated for
User Data messages. User Data messages, as well as Link Status messages that must remain
in sequence with the User Data messages.
The following Link Status messages SHALL be sent on the Link Status
stream (stream 0):
- Alignment
- Proving Normal
- Proving Emergency
- Ready (when sent during alignment)
- Busy
- Busy Ended
- Out of Service
The following Link Status messages SHALL be sent on the User Data
stream (stream 1):
- Processor Outage
- Processor Recovered
- Ready (when sent at the end of processor outage)
4.1.3 Link Alignment 4.1.3 Link Alignment
The purposes of the alignment procedure are: The purposes of the alignment procedure are:
(1) To provide a handshaking procedure so that both endpoints are (1) To provide a handshaking procedure so that both endpoints are
prepared to send SS7 traffic, and to prevent traffic from being prepared to send SS7 traffic, and to prevent traffic from being
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
skipping to change at page 26, line 44 skipping to change at page 25, line 6
procedure. The Link Status Alignment message SHOULD NOT be transmitted procedure. The Link Status Alignment message SHOULD NOT be transmitted
continuously. M2PA MAY send additional Link Status Alignment until it continuously. M2PA MAY send additional Link Status Alignment until it
receives Link Status Alignment, Link Status Proving Normal, or Link receives Link Status Alignment, Link Status Proving Normal, or Link
Status Proving Emergency from the peer. Status Proving Emergency from the peer.
The Link Status Proving Normal message replaces the SIN message of The Link Status Proving Normal message replaces the SIN message of
MTP2. The Link Status Proving Emergency message replaces the SIE MTP2. The Link Status Proving Emergency message replaces the SIE
message of MTP2. message of MTP2.
The proving period MAY be omitted if this is allowed by the applicable The proving period MAY be omitted if this is allowed by the applicable
MTP2 standard (e. g., [Q.2210]). MTP2 standard (e. g., [Q.2140]).
If proving is performed, then during the proving period (i.e., after If proving is performed, then during the proving period (i.e., after
M2PA starts the proving period timer T4), M2PA SHALL send Link Status M2PA starts the proving period timer T4), M2PA SHALL send Link Status
Proving messages to its peer at an interval defined by the protocol Proving messages to its peer at an interval defined by the protocol
parameter Proving_Interval. It is RECOMMENDED that Proving_Interval be parameter Proving_Interval. It is RECOMMENDED that Proving_Interval be
set so that the traffic load generated with the Link Status Proving set so that the traffic load generated with the Link Status Proving
messages during the proving period is comparable to the normal traffic messages during the proving period is comparable to the normal traffic
load expected when the link is in service. load expected when the link is in service.
The Link Status Ready message replaces the FISU of MTP2 that is sent 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 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 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 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 case where MTP2 would send a FISU after proving is complete. If the
send additional Link Status Ready messages while timer T1 is running. Link Status Ready message is sent, then M2PA MAY send additional Link
Status Ready messages while timer T1 is running. These Link Status
Ready messages are sent on the Link Status stream.
In the case that MTP2 sends an MSU or SIPO message at the end of
proving, M2PA SHALL send (respectively) a User Data or Link Status
Processor Outage message.
4.1.4 Processor Outage 4.1.4 Processor Outage
The Link Status Processor Outage message replaces the SIPO message of The Link Status Processor Outage message replaces the SIPO message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Processor Outage message continuously. M2PA SHALL send a Link Status Processor Outage message
to its peer at the beginning of a processor outage condition where to its peer at the beginning of a processor outage condition where
MTP2 would send SIPO. M2PA MAY send additional Link Status Processor MTP2 would send SIPO. M2PA MAY send additional Link Status Processor
Outage messages as long as that condition persists. Outage messages as long as that condition persists. The Link Status
Processor Outage message SHALL be sent on the User Data stream.
When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer. This message is used
to signal in the end of the processor outage condition, instead of an
MSU or FISU as in MTP2. The BSN value in this message is used by the
peer to resynchronize its sequence numbers, if this is required by
MTP2.
While in a local processor outage condition: While in a local processor outage (LPO) condition:
(a) Any User Data messages received from the peer MUST NOT be (a) Any User Data messages received from the peer MUST NOT be
acknowledged and MUST be buffered. acknowledged and MUST be buffered.
(b) M2PA SHOULD continue to acknowledge User Data messages received (b) M2PA SHOULD continue to acknowledge User Data messages received
and accepted by MTP3 before the local processor outage. and accepted by MTP3 before the local processor outage.
While there is a remote processor outage condition: (c) M2PA SHOULD continue to transmit messages that have been sent
by its upper layer MTP3.
(a) Any User Data messages received from the peer after the Link While there is a remote processor outage (RPO) condition:
Status Processor Outage MUST NOT be acknowledged and MUST be
buffered.
(b) M2PA SHOULD continue to acknowledge User Data messages received (a) M2PA SHOULD continue to acknowledge User Data messages received
and accepted by MTP3 before the remote processor outage. and accepted by MTP3 regardless of the remote processor outage.
If M2PA receives a Flush command from MTP3, M2PA SHALL discard the (b) If any User Data messages received from the peer after the Link
incoming messages that were queued and unacknowledged during the Status Processor Outage cannot be delivered to MTP3, then these
processor outage condition. Furthermore, M2PA SHALL discard messages messages MUST NOT be acknowledged and MUST be buffered.
in the transmit and retransmit queues as required by MTP2.
Note that because the Link Status and User Data messages are sent on If M2PA receives a Flush command from MTP3,
separate streams, it is possible for a User Data message sent after
the Link Status Processor Recovered message to arrive before (a) M2PA SHALL discard any incoming messages that were queued and
it. Therefore, when flushing buffers, M2PA must take care not to flush unacknowledged during the processor outage condition.
messages sent after the remote processor recovered. M2PA SHOULD NOT
flush User Data messages with FSN greater than the FSN in the Link (b) M2PA SHALL discard messages in the transmit and retransmit
Status Processor Recovered message. queues as required by MTP2.
If M2PA receives a Continue command from MTP3, M2PA SHALL begin If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged processing the incoming messages that were queued and unacknowledged
during the processor outage condition. during the processor outage condition.
When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer on the User Data
stream. This message is used to signal the end of the processor outage
condition, instead of an MSU or FISU as in MTP2. The BSN in the Link
Status Processor Recovered message is set to the FSN of the last User
Data message received (and not discarded) from the peer M2PA.
Upon receiving the Link Status Processor Recovered message, the M2PA
in RPO SHALL respond with a Link Status Ready message on the User Data
stream. The BSN in the Link Status Ready message is set to the FSN of
the last User Data message received (and not discarded) from the peer
M2PA.
M2PA (at both the LPO and RPO ends) uses the BSN value in the received
Link Status Ready message to resynchronize its sequence numbers, if
this is required by MTP2. M2PA SHALL not resume transmitting User Data
messages until it has received the Link Status Ready message.
During resynchronization, M2PA SHALL NOT discard any received User
Data messages that were sent after the processor outage ended.
When M2PA experiences a local processor outage, it MAY put the link
out of service by sending a Link Status Out of Service message if
allowed by the applicable MTP2 standard (e.g., [Q.2140]).
In other respects, M2PA SHOULD follow the same procedures as MTP2 in In other respects, M2PA SHOULD follow the same procedures as MTP2 in
processor outage. processor outage.
4.1.5 Level 2 Flow Control 4.1.5 Level 2 Flow Control
The Link Status Busy message replaces the SIB message of MTP2. The The Link Status Busy message replaces the SIB message of MTP2. The
message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link
Status Busy message to its peer at the beginning of a receive Status Busy message to its peer at the beginning of a receive
congestion condition where MTP2 would send SIB. M2PA MAY send congestion condition where MTP2 would send SIB. M2PA MAY send
additional Link Status Busy messages as long as that condition additional Link Status Busy messages as long as that condition
persists. When the condition ends, M2PA SHALL send a Link Status Busy persists. When the condition ends, M2PA SHALL send a Link Status Busy
Ended message to its peer. Ended message to its peer.
M2PA SHALL continue transmitting and acknowledging messages while it M2PA SHALL continue transmitting messages while it is in receive
is in receive congestion. congestion, but MUST NOT acknowledge the message that triggered the
sending of the Link Status Busy message, nor any messages received
before the sending of Link Status Busy Ended.
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 if there are messages in
Busy messages received while T6 is running do not cause T6 to be the retransmission buffer awaiting acknowledgement (i.e., T7 is
reset. running). In addition, M2PA SHALL stop the T7 timer if it is running.
Additional Link Status Busy messages received while T6 is running do
not cause T6 to be reset and do not cause T7 to be started. Also,
while T6 is running, T7 SHALL NOT be started.
The peer M2PA SHOULD continue transmitting and acknowledging messages When the peer M2PA receives the Link Status Busy Ended message and T6
while its T6 timer is running, i.e., while the other end is Busy. has not expired, it SHALL stop T6 if T6 is running and start T7 if
there are messages awaiting acknowledgement in the retransmission
buffer.
The peer M2PA SHOULD continue receiving and acknowledging messages
while the other end is busy, but MUST NOT send User Data messages
after receiving Link Status Busy and before receiving Link Status Busy
Ended.
4.1.6 Link Out of Service 4.1.6 Link Out of Service
The Link Status Out of Service message replaces the SIOS message of The Link Status Out of Service message replaces the SIOS message of
MTP2. Unlike MTP2, the message SHOULD NOT be transmitted MTP2. Unlike MTP2, the message SHOULD NOT be transmitted
continuously. M2PA SHALL send a Link Status Out of Service message to continuously. M2PA SHALL send a Link Status Out of Service message to
its peer at the beginning of a condition where MTP2 would send its peer at the beginning of a condition where MTP2 would send
SIOS. M2PA MAY send additional Link Status Out of Service messages as SIOS. M2PA MAY send additional Link Status Out of Service messages as
long as that condition persists. long as that condition persists.
skipping to change at page 29, line 25 skipping to change at page 28, line 8
- The SCTP association is lost. - The SCTP association is lost.
If the SCTP association for a link becomes unable to transmit or 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 receive messages, M2PA SHALL report to MTP3 that the link is out of
service and enter the OUT OF SERVICE state. service and enter the OUT OF SERVICE state.
4.1.8 Transmission and Reception Priorities 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 uses separate
Link Status and User Data messages on separate streams in its SCTP streams in its SCTP association for Link Status messages and User Data
association. M2PA SHALL send all messages using the ordered delivery messages.
option of SCTP.
M2PA SHOULD give higher priority to Link Status messages than to User M2PA SHALL send all messages using the ordered delivery option of
Data messages when sending messages to SCTP. SCTP.
M2PA SHOULD give higher priority to messages sent on the Link Status
stream than to messages sent on the User Data stream 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.9 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
skipping to change at page 31, line 12 skipping to change at page 29, line 12
SHOULD reply with a Link Status Out of Service message and not SHOULD reply with a Link Status Out of Service message and not
complete the alignment procedure. 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.
User Data messages SHALL be sent via stream 1 of the association. User Data messages SHALL be sent via the User Data stream (stream 1)
of the association.
M2PA Link Status messages are passed to SCTP using the SEND primitive. M2PA Link Status messages are passed to SCTP using the SEND primitive.
Link Status messages SHALL be sent via stream 0 of the association. The following Link Status messages SHALL be sent on the Link Status
stream (stream 0):
- Alignment
- Proving Normal
- Proving Emergency
- Ready (when sent during alignment)
- Busy
- Busy Ended
- Out of Service
The following Link Status messages SHALL be sent on the User Data
stream (stream 1):
- Processor Outage
- Processor Recovered
- Ready (when sent at the end of processor outage)
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.
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.
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 place the link out of service (see section 4.1.6 Link Out M2PA SHALL discard the message.
of Service).
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 When there is a message to acknowledge, M2PA MUST acknowledge the
message to acknowledge, M2PA SHOULD send a User Data message with no message with the next User Data message sent. If there is no User
data payload. The FSN for this empty User Data message is not Data message available to be sent when there is a message to
incremented. It MUST contain the same FSN as the most recently sent acknowledge, M2PA SHOULD generate and send a User Data message with no
User Data message containing Data. This message SHOULD be sent data payload, without delay. (In other words, in the case where MTP2
promptly in order to prevent poor SS7 performance. would acknowledge a message with a FISU, M2PA SHOULD acknowledge the
message with an empty User Data message.) The FSN for this empty User
Data message is not incremented. It MUST contain the same FSN as the
most recently sent User Data message containing Data. Delaying of
acknowledgements can result in 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 Link Status messages or empty Note that there is no reason to place Link Status messages or empty
User Data messages in the M2PA retransmit buffer, since these messages User Data messages in the M2PA retransmit buffer, since these messages
are not retrieved for changeover and timer T7 does not apply to them. are not retrieved for 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 within the stream, M2PA does not perform
skipping to change at page 33, line 21 skipping to change at page 31, line 37
(b) any untransmitted User Data messages. (b) any untransmitted User Data messages.
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 and deliver to MTP3 in then M2PA SHALL retrieve from its buffers and deliver to MTP3 in
order: order:
(a) any untransmitted User Data messages. (a) any untransmitted User Data messages.
Note: For the Japanese version of MTP defined in [JT-Q704], MTP3 The Japanese TTC version of MTP defined in [JT-Q703] has a Retrieval
retrieves both unsent and unacknowleged messages for transmission on Request (as well as Retrieval Request and FSNC). The Retrieval Request
the alternate link(s). In this version of MTP, if M2PA receives a allows MTP3 to retrieve both unsent and unacknowleged messages for
Retrieval Request and FSNC request with no FSNC value, or with an transmission on the alternate link(s). In this version of MTP, if M2PA
invalid FSNC, then M2PA SHALL retrieve from its buffers and deliver to receives a Retrieval Request, then M2PA SHALL retrieve from its
MTP3 in order: buffers and deliver to 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.
4.2.3.1 Multiple User Data Streams and Changeover 4.2.3.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
skipping to change at page 39, line 9 skipping to change at page 37, line 9
Out of Service . . . . Out of Service . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Figure 14. 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 15 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 as
[Q.703]. in [Q.703].
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
. M2PA detects . . . . . M2PA detects . . . .
. Local Processor . . . . . Local Processor . . . .
. Outage . . . . . Outage . . . .
. . . . . . . . . . . .
. Link Status . . . . . Link Status . . . .
. Processor Outage . . . . Processor Outage . . .
. ------------> . . . . ------------------------------------> .
. . . . . .
. . (SCTP sends message) . .
. . . . . .
. . . Receive . .
. . . ------------> .
. . . . . . . . . . . .
. . . . Remote Processor . . . . Remote Processor
. . . . Outage . . . . . Outage .
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
. Link Status . . . . Link Status . . .
. Processor Outage . . . . Processor . . .
. Ended . . . . Recovered . . .
. ------------> . . . . ------------------------------------> .
. . . . . . . . . . . .
. . (SCTP sends message) . . . . . . Remote Processor
. . . . Outage Ceases
. . . . ------------>
. . . . . . . . . . . .
. . . Receive . . . . . Link Status Ready .
. . . ------------> . . <------------------------------------ .
. . . . . .
. Link Status Ready . . .
. ------------------------------------> .
. . . . . .
Message for . . . .
transmission . . . .
------------> . . . .
. . . . . .
. User Data . . .
. ------------------------------------> .
. . . . . .
Figure 15. Example: Link Status Message - Processor Outage
Figure 16 shows an example of processor outage in more detail. All
M2PA messages in this example are sent on the Data stream (stream 1).
A B
---------------------------- ----------------------------
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
6 Messages for . . . .
transmission . . . .
------------> . . 6 Messages for
. . . . transmission
. . . . <------------
. User Data FSN=1 . . .
. ------------------------------------> .
. User Data FSN=2 . . .
. ------------------------------------> .
. User Data FSN=3 . . .
. ------------------------------------> .
. . . User Data FSN=11 .
. <------------------------------------ .
. . . User Data FSN=12 .
. <------------------------------------ .
. . . User Data FSN=13 .
. <------------------------------------ .
Side A detects LPO.
. . . . . . . . . . . .
. . . User Data FSN=14 BSN=3 .
. <------------------------------------ .
. . . User Data FSN=15 BSN=3 .
. <------------------------------------ .
. . . User Data FSN=16 BSN=3 .
. <------------------------------------ .
. LS PO FSN=3 BSN=11 . . .
. ------------------------------------> .
. . . . Remote Processor
. . . . Outage .
. . . . ------------>
While in LPO, A must buffer messages 14-16 without acknowledging
them. A may continue transmitting messages from MTP3, and
acknowledging messages that were received before LPO.
. . . . . .
. User Data FSN=4 BSN=13 . . .
. ------------------------------------> .
. User Data FSN=5 BSN=13 . . .
. ------------------------------------> .
. User Data FSN=6 BSN=13 . . .
. ------------------------------------> .
While in RPO, B may continue acknowledging messages. Suppose that B
receives message 4, but has not processed 5 and 6 yet.
. . . . . .
. (empty) User Data FSN=16 BSN=4
. <------------------------------------ .
LPO ends at A. A flushes 14-16 (the messages that were buffered
without acknowledgement).
. . . . . .
. LS PR FSN=6 BSN=13 . . .
. ------------------------------------> .
. . . . Remote Processor . . . . Remote Processor
. . . . Outage Ceases . . . . Outage Ceases
. . . . ------------> . . . . ------------>
. . . . . . . . . . . .
Figure 15. Example: Link Status Message - Processor Outage A should discard any incoming acknowledgements at this point. They
could have been sent before the LS PR.
. . . . . .
. (empty) User Data FSN=16 BSN=5
. <------------------------------------ .
. (discard) . . . .
. . . . . .
B should not resynchronize its sequence numbers now and start with
FSN=14. If B sent a message now with FSN=14, A might confuse this with
a message sent before the LS PR.
Suppose that B processed message 5, but never processed message 6. B
flushes message 6 from its Receive Buffer. B notifies A of this using
the Link Status Ready message:
. . . . . .
. . . LS Ready FSN=16 BSN=5 .
. <------------------------------------ .
. . . . . .
B should discard any incoming acknowledgements at this point. They
could have been sent before B's LS Ready.
A can use the Link Status Ready information to resynchronize its
sequence numbers to begin with FSN=6 for the next User Data message.
. . . . . .
. LS Ready FSN=5 BSN=13 . . .
. ------------------------------------> .
. . . . . .
B can use this information to resynchronize its sequence numbers to
begin with FSN=14. Each side can resume sending User Data:
. . . . . .
Message for . . . Message for
transmission . . transmission
------------> . . <------------
. User Data FSN=6 BSN=13 . . .
. ------------------------------------> .
. . . User Data FSN=14 BSN=5 .
. <------------------------------------ .
. . . . . .
Figure 16. Example: Processor Outage and Recovery
5.5 Level 2 Flow Control 5.5 Level 2 Flow Control
Figures 16 and 17 illustrate the Level 2 Flow Control procedure. In Figures 16 and 17 illustrate the Level 2 Flow Control procedure. In
Figure 16, congestion ceases before timer T6 expires. Figure 17 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
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
skipping to change at page 40, line 35 skipping to change at page 41, 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 16. Example: Level 2 Flow Control - Congestion Ceases Figure 17. 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 41, line 28 skipping to change at page 42, 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 17. Example: Level 2 Flow Control - Timer T6 Expires Figure 18. Example: Level 2 Flow Control - Timer T6 Expires
5.6 MTP3 Signaling Link Congestion 5.6 MTP3 Signaling Link Congestion
In Figure 18, 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
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
skipping to change at page 42, line 33 skipping to change at page 43, 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 18. Example: MTP3 Signalling Link Congestion Figure 19. Example: MTP3 Signalling Link Congestion
5.7 Link Deactivation 5.7 Link Deactivation
Figure 19 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 19. Example: Link Deactivation Figure 20. Example: Link Deactivation
5.8 Link Changeover 5.8 Link Changeover
In Figure 20, 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.
MTP3 M2PA SCTP SCTP M2PA MTP3 MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
. . . . . . . . . . . .
skipping to change at page 45, line 47 skipping to change at page 44, line 53
<------------ . . . . <------------ . . . .
. : . . . . . . : . . . . .
. : . . . . . . : . . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Retrieval Complete . . . . Retrieval Complete . . . .
<------------ . . . . <------------ . . . .
. . . . . . . . . . . .
Send messages on another link. Send messages on another link.
Figure 20. Example: Link Changeover Figure 21. 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: parties:
- the end users of the services - the end users of the services
- the network providers - the network providers
skipping to change at page 49, line 16 skipping to change at page 48, line 16
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, Wayne Davis, Cliff Thomas, comments and suggestions: Brian Tatum, Wayne Davis, Cliff Thomas,
Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina, Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina,
Greg Sidebottom, Al Varney, Jeff Craig, Andrew Booth. Greg Sidebottom, Al Varney, Jeff Craig, Andrew Booth.
9. References 9. References
9.1 Normative 9.1 Normative
[JT-Q703]
TTC, "Message Transfer Part Signalling Link," TTC Standard
JT-Q703, Telecommunication Technology Committee (TTC), version
3 (April 27, 1994).
[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). version 3 (April 28, 1992).
[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).
skipping to change at page 51, line 47 skipping to change at page 50, line 47
Hofmannstr. 51 Hofmannstr. 51
81359 Munich 81359 Munich
Germany Germany
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 December 2003. This Internet Draft expires April 2004.
 End of changes. 

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