draft-ietf-sigtran-m2pa-08.txt   draft-ietf-sigtran-m2pa-09.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 University of North Texas
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Expires October 2003 April 22, 2003 Expires December 2003 June 29, 2003
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-08.txt> <draft-ietf-sigtran-m2pa-09.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 26 skipping to change at page 3, line 26
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...........................................14 2.2 M2PA Header...........................................14
2.3 M2PA Messages.........................................15 2.3 M2PA Messages.........................................15
3. State Control............................................19 3. State Control............................................19
3.1 SCTP Association State Control........................19 3.1 SCTP Association State Control........................19
3.2 M2PA Link State Control...............................20 3.2 M2PA Link State Control...............................20
4. Procedures...............................................21 4. Procedures...............................................21
4.1 Procedures to Support MTP2 Features...................21 4.1 Procedures to Support MTP2 Features...................21
4.2 Procedures to Support the MTP3/MTP2 Interface.........29 4.2 Procedures to Support the MTP3/MTP2 Interface.........31
4.3 SCTP Considerations...................................32 4.3 SCTP Considerations...................................34
5. Examples of M2PA Procedures..............................34 5. Examples of M2PA Procedures..............................35
5.1 Link Initialization (Alignment).......................34 5.1 Link Initialization (Alignment).......................35
5.2 Message Transmission and Reception....................37 5.2 Message Transmission and Reception....................38
5.3 Link Status Indication................................37 5.3 Link Status Indication................................38
5.4 Link Status Message (Processor Outage)................38 5.4 Link Status Message (Processor Outage)................39
5.5 Level 2 Flow Control..................................39 5.5 Level 2 Flow Control..................................40
5.6 MTP3 Signaling Link Congestion........................41 5.6 MTP3 Signaling Link Congestion........................42
5.7 Link Deactivation.....................................42 5.7 Link Deactivation.....................................43
5.8 Link Changeover.......................................43 5.8 Link Changeover.......................................44
6. Security.................................................44 6. Security.................................................46
6.1 Threats...............................................44 6.1 Security Requirements.................................46
6.2 Protecting Confidentiality............................44 6.2 Protecting Confidentiality............................46
7. IANA Considerations......................................45 7. IANA Considerations......................................47
7.1 SCTP Payload Protocol Identifier......................45 7.1 SCTP Payload Protocol Identifier......................47
7.2 M2PA Protocol Extensions..............................45 7.2 M2PA Protocol Extensions..............................47
8. Acknowledgements.........................................46 8. Acknowledgements.........................................49
9. References...............................................47 9. References...............................................49
9.1 Normative..............................................47 9.1 Normative..............................................49
9.2 Informative............................................48 9.2 Informative............................................50
10. Author's Addresses.......................................49 10. Author's Addresses.......................................51
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 5, line 9 skipping to change at page 5, line 9
[Q.702] [Q.703] [Q.704] [Q.705] [T1.111]. [Q.702] [Q.703] [Q.704] [Q.705] [T1.111].
MTP2 - MTP Level 2, the MTP signaling link layer. MTP2 - MTP Level 2, the MTP signaling link layer.
MTP3 - MTP Level 3, the MTP signaling network layer. MTP3 - MTP Level 3, the MTP signaling network layer.
MTP2-User - A protocol that normally uses the services of MTP MTP2-User - A protocol that normally uses the services of MTP
Level 2. The only MTP2 user is MTP3. The MTP2 user is equivalent to Level 2. The only MTP2 user is MTP3. The MTP2 user is equivalent to
the M2PA user. the M2PA user.
Signaling End Point (SEP) - A node in an SS7 network that originates Signaling End Point (SEP) - An SS7 Signaling Point that originates
or terminates signaling messages. One example is a central office or terminates signaling messages. One example is a central office
switch. switch. [RFC2719]
IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP
network connection used for SS7 over IP. network connection used for SS7 over IP.
Signaling Gateway (SG) - A signaling agent that receives/sends SCN Signaling Gateway (SG) - A signaling agent that receives/sends SCN
native signaling at the edge of the IP network [RFC2719]. In this native signaling at the edge of the IP network [RFC2719]. In this
context, an SG is an SS7 Signaling Point that has both an IP network context, an SG is an SS7 Signaling Point that has both an IP network
connection used for SS7 over IP, and a traditional (non-IP) link to an connection used for SS7 over IP, and a traditional (non-IP) link to an
SS7 network. SS7 network.
Signaling Transfer Point (STP) - A node in an SS7 network that routes Signal Transfer Point (STP) - A Signal Transfer Point as defined by MTP
signaling messages based on their destination point code in the SS7 standards, e.g., [Q.700].
network.
Association - An association refers to a SCTP association Signaling Point (STP) - A Signaling Point as defined by MTP standards,
e.g., [Q.700].
Association - An association refers to an SCTP association
[RFC2960]. The association provides the transport for MTP3 protocol [RFC2960]. The association provides the transport for MTP3 protocol
data units and M2PA adaptation layer peer messages. data units and M2PA adaptation layer peer messages.
Network Byte Order - Most significant byte first, also known as "Big Network Byte Order - Most significant byte first, also known as "Big
Endian". See [RFC791], Appendix B "Data Transmission Order". Endian". See [RFC791], Appendix B "Data Transmission Order".
Stream - A stream refers to a SCTP stream [RFC2960]. Stream - A stream refers to an SCTP stream [RFC2960].
1.3 Abbreviations 1.3 Abbreviations
BSNT - Backward Sequence Number to be Transmitted BSNT - Backward Sequence Number to be Transmitted
FSNC - Forward Sequence Number of last message accepted by FSNC - Forward Sequence Number of last message accepted by
remote level 2 remote level 2
LI - Length Indicator LI - Length Indicator
skipping to change at page 8, line 17 skipping to change at page 8, line 17
******** *************** ******** ******** *************** ********
+------+ +------+ +------+ +------+
| TCAP | | TCAP | | TCAP | | TCAP |
+------+ +------+ +------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+ +------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 | | MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA | | MTP2 | | MTP2 | M2PA | | M2PA |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+ | | | +------+ +------+
| | | | IP | | IP | | | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
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.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP * * SEP *--------* SG *--------* IPSP *
******** *************** ******** ******** *************** ********
+------+ +-------------+ +------+ +------+ +-------------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+ +------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 | | MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA | | MTP2 | | MTP2 | M2PA | | M2PA |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+ | | | +------+ +------+
| | | | IP | | IP | | | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
Figure 3. M2PA in IP Signaling Gateway Figure 3. M2PA in IP Signaling Gateway
A comparable architecture for M2UA is shown in Figure 4. In M2UA, the A comparable architecture for M2UA is shown in Figure 4. In M2UA, the
MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer. Likewise, the MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer. Likewise, the
SG's MTP2 uses the MGC's MTP3 as its upper SS7 layer. In SS7, SG's MTP2 uses the MGC's MTP3 as its upper SS7 layer. In SS7,
communication between the MTP3 and MTP2 layers is defined by communication between the MTP3 and MTP2 layers is defined by
primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA
messages and sent over the IP connection. messages and sent over the IP connection.
skipping to change at page 12, line 15 skipping to change at page 12, line 15
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* MGC * * SEP *--------* SG *--------* MGC *
******** *************** ******** ******** *************** ********
+------+ +------+ +------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +------+ +------+ +------+
| MTP3 | (NIF) | MTP3 | | MTP3 | (NIF) | MTP3 |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| MTP2 | | MTP2 | M2UA | | M2UA | | MTP2 | | MTP2 | M2UA | | M2UA |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+ | | | +------+ +------+
| | | | IP | | IP | | | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
Figure 4. M2UA in IP Signaling Gateway Figure 4. M2UA in IP Signaling Gateway
M2PA and M2UA are similar in that: M2PA and M2UA are similar in that:
a. Both transport MTP3 data messages. a. Both transport MTP3 data messages.
skipping to change at page 15, line 25 skipping to change at page 15, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ M2PA-specific Message Header / / M2PA-specific Message Header /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Message Data / / Message Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The field "Message Data" contains either:
- a User Data message (section 2.3.1), or
- a Link State message (section 2.3.2)
2.3.1 User Data 2.3.1 User Data
The User Data is the data sent from MTP3. The User Data is an optional The User Data is the data sent from MTP3. The User Data is an optional
field. It need not be included in an acknowlegement-only message. field. It need not be included in an acknowlegement-only message.
The format for the User Data message is as follows: The format for the User Data message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 41 skipping to change at page 24, line 7
| +------------+------+------------+------+ | | +------------+------+------------+------+ |
| | 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 9 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 SLC 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 26, line 39 skipping to change at page 26, line 43
MTP2. This message is sent to signal the beginning of the alignment MTP2. This message is sent to signal the beginning of the alignment
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.
During the proving period (i.e., after M2PA starts the proving period The proving period MAY be omitted if this is allowed by the applicable
timer T4), M2PA SHALL send Link Status Proving messages to its peer at MTP2 standard (e. g., [Q.2210]).
an interval defined by the protocol parameter Proving_Interval.
If proving is performed, then during the proving period (i.e., after
M2PA starts the proving period timer T4), M2PA SHALL send Link Status
Proving messages to its peer at an interval defined by the protocol
parameter Proving_Interval. It is RECOMMENDED that Proving_Interval be
set so that the traffic load generated with the Link Status Proving
messages during the proving period is comparable to the normal traffic
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. M2PA MAY
send additional Link Status Ready messages while timer T1 is running. send additional Link Status Ready messages while timer T1 is running.
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. When the condition Outage messages as long as that condition persists.
ends, M2PA SHALL send a Link Status Processor Recovered message to its When the local processor outage condition ends, M2PA SHALL send a Link
peer. 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 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.
(c) M2PA SHOULD continue running the T7 timer for messages sent
before the local processor outage.
While there is a remote processor outage condition: While there is a remote processor outage condition:
(a) Any User Data messages received from the peer after the Link (a) Any User Data messages received from the peer after the Link
Status Processor Outage MUST NOT be acknowledged and MUST be Status Processor Outage MUST NOT be acknowledged and MUST be
buffered. 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 remote processor outage. and accepted by MTP3 before the remote processor outage.
If M2PA receives a Flush command from MTP3, M2PA SHALL discard the
incoming messages that were queued and unacknowledged during the
processor outage condition. Furthermore, M2PA SHALL discard messages
in the transmit and retransmit queues as required by MTP2.
Note that because the Link Status and User Data messages are sent on
separate streams, it is possible for a User Data message sent after
the Link Status Processor Recovered message to arrive before
it. Therefore, when flushing buffers, M2PA must take care not to flush
messages sent after the remote processor recovered. M2PA SHOULD NOT
flush User Data messages with FSN greater than the FSN in the Link
Status Processor Recovered message.
If M2PA receives a Continue command from MTP3, M2PA SHALL begin
processing the incoming messages that were queued and unacknowledged
during the processor outage condition.
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 Processor Outage messages as long as that additional Link Status Busy messages as long as that condition
condition persists. When the condition ends, M2PA SHALL send a Link persists. When the condition ends, M2PA SHALL send a Link Status Busy
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 and acknowledging messages while it
is in receive 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.
The peer M2PA SHOULD continue transmitting and acknowledging messages The peer M2PA SHOULD continue transmitting and acknowledging messages
skipping to change at page 29, line 53 skipping to change at page 31, line 29
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 place the link out of service (see section 4.1.6 Link Out
of Service). of Service).
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 SHOULD send a User Data message with no message to acknowledge, M2PA SHOULD send a User Data message with no
data 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. This message SHOULD be sent User Data message containing Data. This message SHOULD be sent
promptly in order to prevent poor SS7 performance. 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 Link Status messages or empty
M2PA retransmit buffer, since the empty messages are not retrieved for User Data messages in the M2PA retransmit buffer, since these messages
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
retransmissions. Nevertheless, M2PA SHALL retain transmitted User Data retransmissions. Nevertheless, M2PA SHALL retain transmitted User Data
messages in a retransmit queue until they are acknowledged. These messages in a retransmit queue until they are acknowledged. These
messages are needed in case MTP3 performs data retrieval as part of a messages are needed in case MTP3 performs data retrieval as part of a
changeover procedure. changeover procedure.
Because propagation delays in IP networks are more variable than in Because propagation delays in IP networks are more variable than in
traditional SS7 networks, a single T7 timer (excessive delay of traditional SS7 networks, a single T7 timer (excessive delay of
acknowledgement) is inadequate. A T7 timer SHALL be started for each acknowledgement) as in MTP2 is inadequate. If any message is
message in the M2PA retransmit buffer. unacknowledged after a period equal to the T7 value, the T7 timer
SHALL expire.
4.2.2 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 MTP3, e.g., requirements for signaling link transmit congestion in MTP3, e.g.,
Q.704 [Q.704], section 3.8. Q.704 [Q.704], section 3.8.
4.2.3 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
skipping to change at page 30, line 55 skipping to change at page 32, line 29
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
messages in the retransmission buffer of the unavailable messages in the retransmission buffer of the unavailable
signaling link which have not been received by the far end signaling link which have not been received by the far end
M2PA, as well as untransmitted messages, and M2PA, as well as untransmitted messages, and
(2) transferring those messages to the transmission buffers of the (2) transferring those messages to the transmission buffers of the
alternate links. alternate links.
Note that only User Data messages are retrieved and transmitted over Note that only User Data messages containing data are retrieved and
transmitted over the alternate links. Link Status messages and empty
the alternate links. Link Status messages SHALL NOT be retrieved and User Data messages SHALL NOT be retrieved and transmitted over the
transmitted over the alternate links. alternate links.
M2PA's Sequence Numbers are 24 bits long. MTP2's Forward and Backward M2PA's Sequence Numbers are 24 bits long. MTP2's Forward and Backward
Sequence Numbers are only seven bits long. Hence it is necessary for Sequence Numbers are only seven bits long. Hence it is necessary for
MTP3 to accommodate the larger sequence numbers. This is done through MTP3 to accommodate the larger sequence numbers. This is done through
the use of the Extended Changeover Order (XCO) and Extended Changeover the use of the Extended Changeover Order (XCO) and Extended Changeover
Acknowledgement (XCA) messages instead of the Changeover Order (COO) Acknowledgement (XCA) messages instead of the Changeover Order (COO)
and Changeover Acknowledgement (COA) messages. The XCO and XCA and Changeover Acknowledgement (COA) messages. The XCO and XCA
messages are specified in [Q.2210] section 9.8.1 and T1.111.4 messages are specified in [Q.2210] section 9.8.1 and T1.111.4
[T1.111], section 15.4. Only the XCO and XCA messages from [Q.2210] or [T1.111], section 15.4. Only the XCO and XCA messages from [Q.2210] or
[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
skipping to change at page 36, line 7 skipping to change at page 37, line 7
. . . . . . . . . . . .
. Stop timer T2 . . . . Stop timer T2 . . .
. . . . . . . . . . . .
Proving period begins. Proving period begins.
Figure 11. 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 . . . . Start timer T3 . . .
. Link Status Proving . . .
. ------------------------------------> .
. . . . . . . . . . . .
. . . Link Status Proving . . . . Link Status Proving .
. <------------------------------------ . . <------------------------------------ .
. . . . . . . . . . . .
. Stop timer T3 . . . . Stop timer T3 . . .
. . . . . . . . . . . .
. Start timer T4 . . .
. Link Status Proving . . . . Link Status Proving . . .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. ------------------------------------> . . ------------------------------------> .
. . . . . . . . . . . .
. Timer T4 expires . . . . Timer T4 expires . . .
. . . . . . . . . . . .
skipping to change at page 46, line 45 skipping to change at page 49, line 8
(c) Detailed definition of each component of the parameter value. (c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type, (d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within 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, Wayne Davis, Cliff Thomas,
Wayne Davis, Malleswar Kalla, Cliff Thomas, Ian Rytina, Greg Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina,
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-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).
skipping to change at page 49, line 8 skipping to change at page 51, line 17
ITU-T Recommendation Q.705, ITU-T Telecommunication ITU-T Recommendation Q.705, ITU-T Telecommunication
Standardization Sector of ITU (March 1993). Standardization Sector of ITU (March 1993).
[RFC2719] [RFC2719]
L. Ong, et. al., "Framework Architecture for Signaling L. Ong, et. al., "Framework Architecture for Signaling
Transport," RFC 2719, The Internet Society (October 1999). 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 EMail: Tom.George@alcatel.com Alcatel EMail: Tom.George@Alcatel.com
3400 West Plano Parkway 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-940-565-2822
Netrake Corporation EMail: rdantu@netrake.com Assistant Professor EMail: rdantu@unt.edu
3000 Technology Drive, Suite 100 Department of Computer Science
Plano 75074 University of North Texas
Denton, TX 76203
USA 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 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
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 October 2003. This Internet Draft expires December 2003.
 End of changes. 

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