Signaling Transport Working Group J. Craig Internet Draft Tekelec Expires: November 8, 2006 May 8, 2006 M2PA Implementer's guide Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 8, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document contains a compilation of all defects found up until the publication date for M2PA RFC4165 [RFC4165]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M2PA to remove ambiguities and correct errors in the original M2PA document. This document updates RFC4165 [RFC4165] and text within this document supersedes the text found in RFC4165. Craig Expires - November 8, 2006 [Page 1] Internet-Draft M2PA Implementer's Guide May 8, 2006 Table of Contents 1. Introduction.....................................................3 1.1. Overview....................................................3 1.2. Terminology.................................................3 1.3. Abbreviations...............................................4 2. Changes to RFC4165...............................................4 2.1. Add Error Rate Monitors.....................................4 2.1.1. Problem Description.....................................4 2.1.2. Solution Description....................................5 2.1.3. Text Changes............................................5 2.2. Clarify Initial FSN and BSN Values..........................7 2.2.1. Problem Description.....................................7 2.2.2. Solution Description....................................7 2.2.3. Text Changes............................................7 2.3. Clarify Local Busy Procedure................................8 2.3.1. Problem Description.....................................8 2.3.2. Solution Description....................................8 2.3.3. Text Changes............................................8 2.4. Clarify Remote Busy Procedure...............................9 2.4.1. Problem Description.....................................9 2.4.2. Solution Description....................................9 2.4.3. Text Changes...........................................10 2.5. Link Status Ready Message Received During Proving..........11 2.5.1. Problem Description....................................11 2.5.2. Solution Description...................................12 2.5.3. Text Changes...........................................12 2.6. Clarify Processor Outage...................................13 2.6.1. Problem Description....................................13 2.6.2. Solution Description...................................14 2.6.3. Text Changes...........................................15 2.7. Clarify Treatment of Received FSN..........................19 2.7.1. Problem Description....................................19 2.7.2. Solution Description...................................19 2.7.3. Text Changes...........................................19 2.8. Provide More M2PA Procedure Examples.......................20 2.8.1. Problem Description....................................20 2.8.2. Solution Description...................................21 2.8.3. Terminology and Tokens Used in Example Figures.........21 2.8.4. Aligned Not Ready Example 1 for [T1.111] Variant.......22 2.8.5. Aligned Not Ready Example 2 for [T1.111] Variant.......24 2.8.6. Aligned Not Ready Example 3 for [T1.111] Variant.......26 2.8.7. PO Example (Clear Buffers) [T1.111] Variant............27 2.8.8. PO Example (Resume) [T1.111] Variant...................28 2.8.9. PO Example (Synchronization) [T1.111] Variant..........30 2.8.10. PO Example (LPO and RPO onset) [T1.111] Variant.......34 2.8.11. PO Example (LPO and RPO abate) [T1.111] Variant.......36 2.8.12. L2 Busy Example (Simple) [T1.111] Variant.............37 Craig Expires - November 8, 2006 [Page 2] Internet-Draft M2PA Implementer's Guide May 8, 2006 2.8.13. L2 Busy Example (With FSN) [T1.111] Variant...........38 2.8.14. Simultaneous Busy and PO Example [T1.111] Variant.....41 3. Security Considerations.........................................43 4. Acknowledgments.................................................43 5. References......................................................43 Appendix A. Changes Control........................................44 Author's Address...................................................44 Intellectual Property Statement....................................45 Disclaimer of Validity.............................................45 Copyright Statement................................................45 Acknowledgement....................................................45 1. Introduction 1.1. Overview This document contains a compilation of all defects found up until the publication date for the Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) User Peer-to-Peer Adaptation Layer (M2PA) [RFC4165]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M2PA to remove ambiguities abd correct errors in the original M2PA document. This document updates RFC4165 and text within this document, where noted, supersedes the text found in RFC4165. Each error and clarification will be detailed within this document in the form of: o The problem description, o A description of the solution, o The text quoted from RFC4165, if applicable, o The new or replacement text. 1.2. Terminology This document uses the terms described in [RFC4165], in addition to the following: Empty User Data Message - a M2PA message having a message type value of 'User Data' and a Message Data field having a length of zero. This message is used to acknowledge reception of non-empty User Data messages when there are no non-empty User Data messages to be sent. This kind of message does not contain user data. Craig Expires - November 8, 2006 [Page 3] Internet-Draft M2PA Implementer's Guide May 8, 2006 Non-Empty User Data Message - a M2PA message having a message type value of 'User Data' and a Message Data field having a length greater than zero. This kind of message contains user data. 1.3. Abbreviations This document uses the abbreviations described in [RFC4165], in addition to the following: ACK - Acknowledgement AERM - Alignment Error Rate Monitor L2 - M2PA or MTP2 L3 - MTP3 LS - Link Status PO - Processor Outage PR - Processor Recovered RB - Receive Buffer RTB - Retransmit Buffer SUERM - Signaling Unit Error Rate Monitor TB - Transmit Buffer 2. Changes to RFC4165 2.1. Add Error Rate Monitors 2.1.1. Problem Description RFC4165 section 4.1.1 states "Since SCTP uses a checksum to detect transmission errors, there is no need for an M2PA checksum, as is needed in MTP2. This also eliminates the need for the error rate monitors of MTP2." M2PA uses a SCTP/IP transport that can involve shared network resources and for which available capacity can vary dramatically over time. The SCTP/IP network quality of service characteristics can be such that, without an error rate monitor function, a M2PA signaling link will enter service and yet operate unreliably, possibly entering congestion or failing intermittently due to timer T7 expiration. MTP2 standards provide an Alignment Error Rate Monitor (AERM) function used to determine the viability of a transport prior to placing a signaling link in service. M2PA should provide an equivalent for this function, one that is aware of the characteristics of the SCTP/IP transport. Craig Expires - November 8, 2006 [Page 4] Internet-Draft M2PA Implementer's Guide May 8, 2006 MTP2 standards provide a Signaling Unit Error Rate Monitor (SUERM) function used to detect degraded transport operation and fail a signaling link when transport quality of service is not sufficient. M2PA should provide an equivalent for this function, one that is aware of the characteristics of the SCTP/IP transport. 2.1.2. Solution Description Add new text that describes the M2PA Alignment Error Rate Monitor and the M2PA Signaling Unit Error Rate Monitor. 2.1.3. Text Changes Original Text (RFC4165 section 4.1.1) --------------------------------------------------------------------- Since SCTP uses a checksum to detect transmission errors, there is no need for an M2PA checksum, as is needed in MTP2. This also eliminates the need for the error rate monitors of MTP2. --------------------------------------------------------------------- New Text (RFC4165 section 4.1.1) --------------------------------------------------------------------- Since SCTP uses a checksum to detect transmission errors, there is no need for an M2PA checksum, as is needed in MTP2. --------------------------------------------------------------------- New Text (RFC4165 section 4.2.4) --------------------------------------------------------------------- 4.2.4. Alignment Error Rate Monitor (AERM) The MTP2 standards, e.g. [Q.703] section 10.3, describe the alignment error rate monitor. If M2PA uses a SCTP implementation that provides the ability to query round-trip-time and retransmit data for a particular association, it is RECOMMENDED that M2PA use those interfaces during proving (timer T4 is running) to ensure that the transport meets implementation- dependent quality of service requirements. An example set of quality of service requirements is: average RTT during proving must be less than or equal to 100ms, and the maximum rate of retransmissions allowed during proving is 1 per 1000 messages transmitted. It is RECOMMENDED that M2PA allow the proving state quality of service parameters to be administered by the user. If M2PA determines that quality of service requirements are not met, and the proving procedure has been aborted less than four times, then M2PA SHOULD abort the current proving period, count the aborted Craig Expires - November 8, 2006 [Page 5] Internet-Draft M2PA Implementer's Guide May 8, 2006 proving period, and restart proving. If M2PA determines that quality of service requirements are not met, and proving has already been aborted four times, then M2PA SHOULD move the signaling link to the out of service state. --------------------------------------------------------------------- New Text (RFC4165 section 4.2.5) --------------------------------------------------------------------- 4.2.5. Signaling Unit Error Rate Monitor (SUERM) The MTP2 standards, e.g. [Q.703] section 10.2, describe the signaling unit error rate monitor. If M2PA uses a SCTP implementation that provides the ability to query round-trip-time and retransmit data for a particular association, it is RECOMMENDED that M2PA use those interfaces while the signaling link is in service to ensure that the transport meets implementation- dependent quality of service requirements. An example set of quality of service requirements is: average RTT while in service must be less than or equal to 100ms, and the maximum rate of retransmissions allowed while in-service is 1 in 1000. It is RECOMMENDED that M2PA allow the in service state quality of service parameters to be administered by the user. If M2PA determines that quality of service requirements are not met, then M2PA SHOULD move the signaling link to the out of service state. --------------------------------------------------------------------- New Text (RFC4165 section 4.3.2) --------------------------------------------------------------------- 4.3.2. SCTP Quality of Service Statistics M2PA relies upon SCTP to provide a reliable communication transport, and so quality of service statistics such as round-trip time and retransmission counts are properly kept by SCTP. It is RECOMMENDED that M2PA use an SCTP implementation that has the following characteristics: - provides an interface for the user to obtain the last measured network round-trip-time (time from when a packet containing user data was sent to the time reception was acknowledged) for a particular association - provides an interface for the user to obtain the number of retransmissions that have been performed for a particular association Craig Expires - November 8, 2006 [Page 6] Internet-Draft M2PA Implementer's Guide May 8, 2006 An SCTP implementation that provides M2PA visibility into quality of service statistics for an association allows M2PA to implement the alignment error rate monitor and signaling unit error rate monitor. --------------------------------------------------------------------- 2.2. Clarify Initial FSN and BSN Values 2.2.1. Problem Description RFC4165 does not state what the M2PA initial FSN and BSN must be, though it cites applicable MTP2 standards. M2PA implementers have chosen different initial FSN values, leading to M2PA interoperability problems. 2.2.2. Solution Description Add new text that describes the initial FSN and BSN values for two common MTP2 variants. 2.2.3. Text Changes Original Text (RFC4165 section 2.2.2) --------------------------------------------------------------------- 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. --------------------------------------------------------------------- New Text --------------------------------------------------------------------- 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. An M2PA that conforms to either Q.703 [Q.703] or T1.111.3 [T1.111] SHALL set the FSN value of the first transmitted non-empty User Data message to 0. An M2PA that conforms to either Q.703 [Q.703] or T1.111.3 [T1.111] SHALL, if no non-empty User Data messages have been received, set the BSN value of the first transmitted user data message to 16,777,215. --------------------------------------------------------------------- Craig Expires - November 8, 2006 [Page 7] Internet-Draft M2PA Implementer's Guide May 8, 2006 2.3. Clarify Local Busy Procedure 2.3.1. Problem Description RFC1645 does not state that M2PA MUST buffer non-empty user data messages received after a Link Status Busy message has been sent and before Link Status Busy Ended has been sent. The RFC does not describe the treatment of the buffered messages when a primitive, such as Flush or Clear Buffers is received from MTP3. This ambiguity may lead to M2PA busy procedure interoperability problems. 2.3.2. Solution Description Revise the text such that it states that M2PA MUST buffer received non-empty user data messages during the local busy condition and that it MUST discard the buffered messages if it receives a Flush or Clear Buffers primitive from MTP3. 2.3.3. Text Changes Original Text (section 4.1.5) --------------------------------------------------------------------- The Link Status Busy message replaces the SIB message of MTP2. The 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 Busy 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 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. --------------------------------------------------------------------- New Text --------------------------------------------------------------------- Upon receiving a User Data message that causes implementation- dependent onset of receive congestion, M2PA SHALL NOT acknowledge the message, SHALL mark the local congestion condition, and SHALL send a Link Status Busy message to the peer. The Link Status Busy message replaces the SIB message of MTP2. While in the local congestion condition: Craig Expires - November 8, 2006 [Page 8] Internet-Draft M2PA Implementer's Guide May 8, 2006 (a) M2PA SHALL, if other conditions allow, continue transmitting messages. (b) M2PA MUST NOT acknowledge and MUST buffer any received non- empty User Data message. (c) Upon receiving a Flush command from MTP3, M2PA SHALL discard any received messages that were buffered and unacknowledged during the local congestion condition, send a Link Status Busy Ended message to the peer, and clear the local congestion condition. (d) Upon detecting that the receive congestion has abated, M2PA SHALL send a Link Status Busy Ended message to the peer, clear the local congestion condition, and process and acknowledge any received messages that had been buffered and unacknowledged during the local busy condition. (e) M2PA MAY periodically send, but MUST NOT continuously send, Link Status Busy messages to the peer. --------------------------------------------------------------------- 2.4. Clarify Remote Busy Procedure 2.4.1. Problem Description It is not clear in RFC4165 section 4.1.5 that timer T6 MUST be running while remote congestion status is in effect. RFC4165 does not clearly distinguish empty and non-empty User Data messages when it states that M2PA MUST NOT send User Data messages to a busy peer. M2PA SHOULD send empty User Data messages to a busy peer in order to acknowledge received messages. 2.4.2. Solution Description Revise the text such that it states that M2PA SHALL mark remote congestion status and start T6 if and only if it receives Link Status Busy when T6 is not running, and the RTB contains one or more messages. Revise the text such that it states that M2PA SHOULD acknowledge messages received from a busy peer but MUST NOT send non-empty user data messages to a busy peer. Craig Expires - November 8, 2006 [Page 9] Internet-Draft M2PA Implementer's Guide May 8, 2006 Clarify that M2PA SHOULD cancel remote congestion status if its RTB becomes empty. 2.4.3. Text Changes Original Text (section 4.1.5) --------------------------------------------------------------------- When the peer M2PA receives the first Link Status Busy message, it SHALL start the Remote Congestion timer T6 if there are messages in the retransmission buffer awaiting acknowledgement (i.e., T7 is running). 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. While T6 is running, T7 SHALL NOT be started. When the peer M2PA receives the Link Status Busy Ended message and T6 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. --------------------------------------------------------------------- New Text --------------------------------------------------------------------- Upon receiving a Link Status Busy message, if the remote congestion condition is not already in effect, and the RTB contains at least one message, then M2PA SHALL mark the remote congestion condition, start the Remote Congestion timer T6, and stop a running timer T7. M2PA SHALL ignore a Link Status Busy message received when either the RTB is empty or the remote congestion condition is in effect. While the remote congestion condition is in effect: (a) M2PA timer T6 is running (or expired). (b) M2PA MUST NOT send non-empty User Data messages. (c) M2PA MUST NOT start timer T7. (d) M2PA SHOULD continue receiving and acknowledging messages. (e) M2PA SHALL ignore received Link Status Busy messages. (f) M2PA SHALL, upon receiving a Link Status Busy Ended message, Craig Expires - November 8, 2006 [Page 10] Internet-Draft M2PA Implementer's Guide May 8, 2006 stop timer T6, cancel the remote congestion condition, and start timer T7 if the RTB contains one or more messages requiring acknowledgement. (g) M2PA SHOULD, upon receiving an acknowledgement that causes the RTB to become empty, stop timer T6 and cancel the remote congestion condition. --------------------------------------------------------------------- 2.5. Link Status Ready Message Received During Proving 2.5.1. Problem Description The M2PA link could fail to go in service if M2PA ignores Link Status Ready messages received while timer T4 is running. Consider the example depicted by Figure 1 where 'X<--' and '-->X' indicate a message received and ignored: (For the diagram key, see 2.8.3). MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . . Start T4 . . . . . . . . . . . LS Proving-------------------------->X . . . . . . . . . . . Start T4 . . . . . . . . X<--------------------------LS Proving . . . . . . . . T4 expires . . . . . Start T1 . . . . . LS Ready---------------------------->X . . Aligned . . . . . Ready . . . . . . . . . . . X<--------------------------LS Proving . . . . . . . . . . . T4 expires . . . . . Start T1 . . <----------------------------LS Ready . . . . . Aligned . . . . . Ready . . . . . . . <-----L2L3INS . . . . Craig Expires - November 8, 2006 [Page 11] Internet-Draft M2PA Implementer's Guide May 8, 2006 . Stop T1 . . . . . In Service . . . . . . . . . . . . . . T1 Expires . . . . . L2L3OOS-----> . <------------------------------LS OOS . . . . . . . <-----L2L3OOS . . . . . LS OOS------------------------------> . . . . . . . Figure 1. Example LS Ready Ignored During Proving Because the right side M2PA ignored the Link Status Ready message that it received while its timer T4 was running, it started its timer T1, and its timer T1 later expired because no subsequent Link Status Ready message was received. There would be a similar result if the left side M2PA had sent a Link Status Processor Outage message that was received during proving and ignored by the right side M2PA. 2.5.2. Solution Description Revise the RFC to state that M2PA SHOULD mark Link Status Ready message received or Link Status Processor outage message received while timer T4 is running, and that upon T4 expiration, if either message had been received, then M2PA SHOULD NOT start timer T1, and instead SHOULD operate as if the message was received immediately after it would normally have started timer T1. 2.5.3. Text Changes Original Text (4.1.3. Link Alignment) --------------------------------------------------------------------- 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. If the 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. Craig Expires - November 8, 2006 [Page 12] Internet-Draft M2PA Implementer's Guide May 8, 2006 --------------------------------------------------------------------- New Text --------------------------------------------------------------------- The Link Status Ready message replaces the FISU of MTP2 that is sent at the end of the proving period. Unlike MTP2, the message SHOULD NOT be transmitted continuously. M2PA SHALL, when no local processor outage is in effect, use the Link Status Ready message to signal to the peer that it has completed proving. The Link Status Processor Outage message replaces the SIPO message of MTP2. Unlike MTP2, the message SHOULD NOT be transmitted continuously. M2PA SHALL use the Link Status Processor Outage message to signal to the peer that it has completed proving and that local processor outage is in effect. The Link Status Processor Outage message SHALL be sent on the User Data stream. While timer T4 is running, M2PA SHOULD mark reception of either a Link Status Ready message or a Link Status Processor Outage message. Upon expiration of timer T4, M2PA SHOULD check whether a Link Status Ready message or a Link Status Processor Outage message was received, and if either message was received, M2PA SHOULD NOT start timer T1 and instead SHOULD operate as if the message had been received after timer T1 had been started. If neither message was received during proving, then M2PA SHOULD start timer T1 and proceed according to the applicable MTP2 standard. Upon expiration of timer T4, M2PA SHALL send a Link Status Ready message to its peer in the case where MTP2 would send a FISU and SHALL send a Link Status Processor Outage message to its peer in the case where MTP2 would send a SIPO. In the case that MTP2 sends a MSU at the end of proving, M2PA SHALL send a User Data message. If a 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. If a Link Status Processor Outage message is sent, then M2PA MAY send additional Link Status Processor Outage messages while timer T1 is running. These Link Status Processor Outage messages are sent on the User Data stream. --------------------------------------------------------------------- 2.6. Clarify Processor Outage 2.6.1. Problem Description Craig Expires - November 8, 2006 [Page 13] Internet-Draft M2PA Implementer's Guide May 8, 2006 RFC4165 summarizes a processor outage procedure that deviates significantly from the cited MTP2 standards. The lack of detail in the RFC's description of the procedure has led to implementation difficulty and to interoperability problems. One example of ambiguity is that it is not clear that the meaning of a received Link Status Ready message depends upon the association stream used to transport the message, as well as upon local and remote processor outage status. Another example of ambiguity is that it is unclear whether Link Status Processor Recovered or Link Status Ready is used to synchronize sequence numbers when a remote processor recovers. A summary of M2PA processor outage procedure deviations from MTP2 follows: o The Link Status Processor Outage message replaces the MTP2 SIPO, is not sent continuously, and is not required to be sent more than once. o The Link Status Processor Recovered message replaces the MTP2 FISU or MSU sent after local processor outage condition clears and is not sent continuously. o The Link Status Ready message sent on the User Data stream replaces the MTP2 FISU or MSU sent after remote processor outage clears and is not sent continuously. The Link Status Ready message sent on the Link Status stream indicates the end of proving with no local processor outage condition in effect. During alignment M2PA MUST distinguish the meaning of received Link Status Ready based upon the association stream upon which it is received. o While in local processor outage, M2PA buffers received User Data messages without acknowledgement, whereas MTP2 discards received MSUs. o M2PA must not transmit User Data messages after it sends Link Status Processor Recovered until it receives a Link Status Ready message on the User Data stream. Bounding the Link Status Ready waiting period is implementation dependent. MTP2 variants, such as [T1.111], are able to send either a FISU (sent continuously) or a MSU to indicate processor recovered status. o The M2PA procedure for synchronizing sequence numbers when local processor outage clears is unbounded, unless M2PA implements a timer to establish a maximum time to wait for received Link Status Ready on the user data stream. 2.6.2. Solution Description Craig Expires - November 8, 2006 [Page 14] Internet-Draft M2PA Implementer's Guide May 8, 2006 Clarify the M2PA processor outage procedure deviations from the cited MTP2 standards. Separate discussion of the local and remote processor outage procedures. Clarify that the M2PA experiencing remote processor outage uses the BSN of the received Link Status Processor Recovered message to synchronize its FSN. Clarify that the M2PA experiencing local processor outage uses the BSN of the Link Status Ready message received on the User Data stream to synchronize its FSN. Clarify treatment of buffered and unacknowledged non-empty User Data messages. Clarify treatment of received Link Status Processor Recovered when M2PA is experiencing both local and remote processor outage conditions. Clarify that treatment of received Link Status Ready message is based upon the association stream upon which it is received, as well as local and remote processor outage status. 2.6.3. Text Changes Original Text (4.1.4. Processor Outage) --------------------------------------------------------------------- The Link Status Processor Outage message replaces the SIPO message of 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. The Link Status Processor Outage message SHALL be sent on the User Data stream. While in a local processor outage (LPO) condition: (a) Any User Data messages received from the peer MUST NOT be acknowledged and MUST be buffered. (b) M2PA SHOULD continue to acknowledge User Data messages received and accepted by MTP3 before the local processor outage. (c) M2PA SHOULD continue to transmit messages that have been sent by its upper layer MTP3. While there is a remote processor outage (RPO) condition: (a) M2PA SHOULD continue to acknowledge User Data messages received and accepted by MTP3, regardless of the remote processor outage. (b) If any User Data messages received from the peer after the Link Status Processor Outage cannot be delivered to MTP3, then these messages MUST NOT be acknowledged and MUST be Craig Expires - November 8, 2006 [Page 15] Internet-Draft M2PA Implementer's Guide May 8, 2006 buffered. If M2PA receives a Flush command from MTP3, (a) M2PA SHALL discard any incoming messages that were queued and unacknowledged during the processor outage condition. (b) M2PA SHALL discard messages in the transmit and retransmit queues as required by MTP2. 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. 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 is used 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. M2PA SHALL cease transmitting User Data messages after sending the Link Status Processor Recovered message, until it has received the Link Status Ready message(see below). 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. Upon receiving the Link Status Ready message, the M2PA formerly in LPO 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 sent 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 this is allowed by the applicable MTP2 standard (e.g., [Q.2140]). Craig Expires - November 8, 2006 [Page 16] Internet-Draft M2PA Implementer's Guide May 8, 2006 In other respects, M2PA SHOULD follow the same procedures as MTP2 in processor outage. --------------------------------------------------------------------- New Text --------------------------------------------------------------------- MTP2 standards, e.g. [Q.703] chapter 8, describe processor outage. M2PA's support for the procedure differs somewhat from that of MTP2. The Link Status Processor Outage message replaces the SIPO message of MTP2. Unlike MTP2, the message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link Status Processor Outage message to its peer when conditions would cause MTP2 to send SIPO. M2PA SHALL send the Link Status Processor Outage message on the User Data stream. The Link Status Processor Recovered message replaces the FISU or MSU that MTP2 sends to indicate an end to a local processor outage condition, and the message SHOULD NOT be transmitted continuously. M2PA SHALL send the Link Status Processor Recovered message on the User Data stream. M2PA SHALL set the BSN in the Link Status Processor Recovered message to the FSN of the last non-empty User Data message received and not discarded from the peer M2PA. M2PA SHALL use the BSN of a received Link Status Processor Recovered message to synchronize its FSN. The Link Status Ready message sent on the User Data stream replaces the FISU or MSU that MTP2 sends to acknowledge the end of a remote processor outage condition. M2PA SHALL set the BSN in the Link Status Ready message to the FSN of the last non-empty User Data message received and not discarded from the peer M2PA. M2PA SHALL use the BSN of a Link Status Ready message received on the User Data stream to synchronize its FSN. When M2PA is notified of a local processor outage, it MAY put the link out of service by sending a Link Status Out of Service message, if this is allowed by the applicable MTP2 standard (e.g. [Q.2140]). While in a local processor outage (LPO) condition: (a) M2PA MUST buffer and MUST NOT acknowledge non-empty User Data messages received from the peer. (b) M2PA SHOULD continue to acknowledge non-empty User Data messages received and accepted by MTP3 before the local processor outage. (c) M2PA SHOULD continue to transmit messages that have been sent by its upper layer MTP3. Craig Expires - November 8, 2006 [Page 17] Internet-Draft M2PA Implementer's Guide May 8, 2006 (d) M2PA MAY periodically send Link Status Processor Outage messages. (e) Upon receiving a primitive from MTP3 that would cause MTP2 to send either a FISU or MSU, M2PA SHALL send a Link Status Processor Recovered message on the User Data stream, MAY start a Waiting for Link Status Ready timer (Tsync), and SHALL NOT transmit non-empty User Data messages. (f) Upon receiving a Link Status Ready message on the User Data stream after sending a Link Status Processor Recovered message, M2PA SHALL synchronize its FSN using the message's BSN, and SHOULD stop a running Waiting for Link Status Ready timer (Tsync). (g) Upon receiving a Link Status Processor Recovered message on the User Data stream after sending a Link Status Processor Recovered message, M2PA SHALL synchronize its FSN using the message's BSN, and SHOULD stop a running Waiting for Link Status Ready timer (Tsync). (h) Upon expiration of the Waiting for Link Status Ready timer (Tsync), M2PA SHOULD take the link out of service. (i) Upon receiving a primitive from MTP3 that would cause MTP2 to clear its RTB, M2PA SHOULD discard the non-empty User Data messages that it received and buffered without acknowledgement. (j) Upon receiving primitive from MTP3 that would cause MTP2 to cancel local processor outage without clearing its buffers, M2PA SHALL begin processing the received non-empty User Data messages that were buffered and unacknowledged. While in a remote processor outage (RPO) condition: (a) M2PA SHOULD continue to acknowledge non-empty User Data messages received and accepted by MTP3. (b) M2PA MUST buffer and MUST NOT acknowledge any received non- empty User Data messages that cannot be delivered to MTP3. (c) Upon receiving a Link Status Processor Recovered message after T4 expiration, M2PA SHALL synchronize its FSN using the message BSN, and SHALL notify MTP3 of remote processor recovery. Upon receiving a Link Status Processor Recovered message while T4 is running, M2PA SHOULD cancel its remote processor outage status. Craig Expires - November 8, 2006 [Page 18] Internet-Draft M2PA Implementer's Guide May 8, 2006 (d) Upon receiving a primitive from MTP3 that would cause MTP2 to send either a FISU or MSU, M2PA SHALL cancel remote processor outage condition and SHALL send a Link Status Ready message on the User Data stream. (e) Upon receiving a primitive from MTP3 that would cause MTP2 to clear its RTB, M2PA SHOULD discard the non-empty User Data messages that it received and buffered without acknowledgement. (f) Upon receiving primitive from MTP3 that would cause MTP2 to cancel remote processor outage without clearing its buffers, M2PA SHALL begin processing the received non-empty User Data messages that were buffered and unacknowledged. M2PA SHALL ignore a Link Status Ready message received on the User Data stream after sequence number synchronization due to local processor recovery completion, i.e. the Waiting for Link Status Ready timer (Tsync) is not running. --------------------------------------------------------------------- 2.7. Clarify Treatment of Received FSN 2.7.1. Problem Description The RFC4165 text that describes the treatment of FSN in received messages does not distinguish empty and non-empty User Data messages and could be clearer in its description of the treatment of FSN for Link Status messages. 2.7.2. Solution Description Revise the text to distinguish empty and non-empty User Data messages. Revise the text to state that M2PA SHALL ignore the FSN of received Link Status messages and empty User Data messages. 2.7.3. Text Changes Original Text (4.1.5. Level 2 Flow Control) --------------------------------------------------------------------- For message types other than User Data, the Forward Sequence Number is 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 Craig Expires - November 8, 2006 [Page 19] Internet-Draft M2PA Implementer's Guide May 8, 2006 order, M2PA SHALL discard the message. --------------------------------------------------------------------- New Text --------------------------------------------------------------------- For message types other than Non-Empty User Data, M2PA SHALL set the Forward Sequence Number (FSN) to be equal to the FSN of the last Non-Empty User Data message sent. M2PA SHALL ignore the FSN of received Link Status messages and Empty User Data messages. M2PA SHALL discard and not acknowledge a received Non-Empty User Data message having a FSN that is out of order. --------------------------------------------------------------------- 2.8. Provide More M2PA Procedure Examples 2.8.1. Problem Description RFC4165 cites MTP2 standards as the basis for its procedures and also specifies significant deviations from those standards. Some deviations from MTP2 are: o M2PA peer-to-peer primitives have names that differ from their MTP2 counterparts and some M2PA primitives serve multiple purposes, e.g. User Data and LS Ready message. o M2PA has peer-to-peer primitives that MTP2 lacks, e.g. LS Busy Ended and LS Processor Recovery. o M2PA does not send Link Status Alignment messages continuously, while MTP2 sends SIO continuously. M2PA does not require that more than one Link Status Alignment message be sent. o M2PA does not send Link Status Ready messages and Empty User Data messages continuously, while MTP2 sends FISU continuously. M2PA does not require that more than one Link Status Ready message be sent. o M2PA does not send Link Status Processor Outage messages continuously, while MTP2 sends SIPO continuously. M2PA does not require that more than one Link Status Processor Outage message be sent. o M2PA buffers User Data messages received during local Craig Expires - November 8, 2006 [Page 20] Internet-Draft M2PA Implementer's Guide May 8, 2006 processor outage, unlike MTP2, which discards them. o M2PA does not retransmit User Data messages, unlike MTP2. o M2PA does not send Link Status Busy messages continuously, while MTP2 sends SIB continuously. M2PA does not require that more than one Link Status Busy message be sent. Some of the RFC's procedure examples lack detail, such as the communication of primitives between M2PA and MTP3 and between implementation-dependent management components and M2PA, and this lack of detail has made some M2PA procedures difficult to implement and has led to M2PA interoperability problems. 2.8.2. Solution Description Provide more examples of M2PA procedures and provide examples that include the communication of primitives between MTP3 and M2PA and between implementation-dependent management components and M2PA. 2.8.3. Terminology and Tokens Used in Example Figures The following summarizes the terms and tokens used in the procedure example figures: Vertical Axis indicates from top to bottom non-linear increasing time Horizontal Axis distinguishes the protocol layers of the peers event-> indicates primitive sent from left to right; destination reached <-event indicates primitive sent from right to left; destination reached event->X indicates primitive received and ignored X<-event indicates primitive received and ignored event->> indicates primitive in flight, not at destination <<-event indicates primitive in flight, not at destination (number) indicates a SCTP stream ID for Link Status messages and FSN of the M2PA User Data message from which a MSU was extracted. Craig Expires - November 8, 2006 [Page 21] Internet-Draft M2PA Implementer's Guide May 8, 2006 {event} indicates an event generated by an implementation- dependent component. Busy RB is the M2PA busy receive buffer in which non-empty User Data messages are stored after being received and not acknowledged during a local busy condition. Last_FSN records the FSN of the last transmitted non-empty User Data message. Next_BSN records the FSN of the last user data message received from the peer requiring acknowledgement. PO_RB is the M2PA processor outage receive buffer in which user data messages are stored after being received and not acknowledged during processor outage condition. RTB is the M2PA retransmit buffer containing MSUs or user data messages that have been transmitted. TB is the M2PA transmit buffer containing MSUs received from MTP3 for transmission. One should note that the diagrams are simplified in the sense that the communication of primitives is often depicted as instantaneous, i.e. the arrow resides on one horizontal line and crosses multiple protocol layers. In reality, the communication always involves the passage of time, and one should keep this in mind when interpreting the diagrams. 2.8.4. Aligned Not Ready Example 1 for [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of local processor outage during link alignment prior to proving. The left side M2PA processor outage condition clears after a Link Status Ready message is received from the right side M2PA. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Unavailable . . . . Unavailable Not Aligned . . . . Not Aligned Not Blocked . . . . Not Blocked . . . . . . {MGMTL2LPO}---> . . . . Craig Expires - November 8, 2006 [Page 22] Internet-Draft M2PA Implementer's Guide May 8, 2006 . Mark LPO . . . . . . . . . . . Start T4 . . . . . . . . Start T4 . . LS Proving-------------------------->X . . X<--------------------------LS Proving . . . . . . . . T4 expires . . . . . . . . . . . Start T1 . . . . . LS PO (1)---------------------------> . . Aligned . . . . . Not Ready . . . . . . . . . . . . . . Mark . . . . . LSPO Rcvd . . . . . . . . X<--------------------------LS Proving . . . . . . . . . . . T4 expires . . <------------------------LS Ready (0) . . . . . L2L3RPO-----> . . . . Mark RPO . . . . . Processor . . . . . Outage . . . . . . . <-----L2L3INS . . . . . Stop T1 . . . . . Processor . . . . . Outage . . . . . LS PO (1)--------------------------->X . . . . . . . . LS PO (1)--------------------------->X . . . . . . . Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . . . . . . . <--L3L2CLRRTB . . . . L2L3RTBCLRD-> . <-------------------------LS Ready (1) . Craig Expires - November 8, 2006 [Page 23] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . In Service . . . . . . . Unavailable . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . <-L2L3RTBCLRD . . . . . LS Ready (1)------------------------>X . . In Service . . . . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . --------------------------------------------------------------------- Figure 2. Aligned Not Ready Example 1 for [T1.111] Variant 2.8.5. Aligned Not Ready Example 2 for [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of local processor outage during link alignment prior to proving. The left side M2PA processor outage condition clears before a Link Status Ready message is received from the right side M2PA. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Unavailable . . . . Unavailable Not Aligned . . . . Not Aligned Not Blocked . . . . Not Blocked . . . . . . {MGMTL2LPO}---> . . . . . Mark LPO . . . . . . . . . . . Start T4 . . . . . . . . Start T4 . . LS Proving-------------------------->X . . X<--------------------------LS Proving . . . . . . . . T4 expires . . . . . . . . . . . Start T1 . . . . . LS PO (1)-------------->> . . . Aligned . . . . Craig Expires - November 8, 2006 [Page 24] Internet-Draft M2PA Implementer's Guide May 8, 2006 . Not Ready . . . . . . . . . . . X<--------------------------LS Proving . . . . . . . . . . . T4 expires . . . . . Start T1 . . . <<-----------LS Ready (0) . . . . . Aligned . . . . . Ready . . . . . . . . . . LS PO (1)---> . . . . . . . . . . . Stop T1 . . . . . L2L3RPO-----> . . . . Mark RPO . . . . . Processor . . . . . Outage . . . . . . . Unavailable . . . . Unavailable Not Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . Aligned . . . . . Ready . . . . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . . . . . . . <--L3L2CLRRTB . . . . L2L3RTBCLRD-> . . <<------------LS Ready (1) . . . . . In Service . . . . . . . . <--LS Ready (0) . . . . Stop T1 . . . . <-----L2L3INS . . . . . Processor . . . . . Outage . . . . . . . . . . Unavailable . . . . Available Aligned . . . . Aligned Blocked . . . . Not Blocked . . . . . . . <--LS Ready (1) . . . . . . . . . Craig Expires - November 8, 2006 [Page 25] Internet-Draft M2PA Implementer's Guide May 8, 2006 . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN <-L2L3RTBCLRD . . . . . LS Ready (1)------------------------>X . . In Service . . . . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . Figure 3. Aligned Not Ready Example 2 for [T1.111] Variant 2.8.6. Aligned Not Ready Example 3 for [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of local processor outage during link alignment prior to proving. The left side M2PA local processor outage condition clears via a L3 resume primitive before the right side M2PA finishes proving. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Unavailable . . . . Unavailable Not Aligned . . . . Not Aligned Not Blocked . . . . Not Blocked . . . . . . {MGMTL2LPO}---> . . . . . Mark LPO . . . . . . . . . . . Start T4 . . . . . . . . Start T4 . . LS Proving-------------------------->X . . X<--------------------------LS Proving . . . . . . . . T4 expires . . . . . . . . . . . Start T1 . . . . . LS PO (1)---------------------------> . . Aligned . . Mark RPO . . Not Ready . . . . . . . . . . . X<--------------------------LS Proving . . . . . . . L3L2RESUME--> . . . . . Cancel LPO . . . . . Aligned Ready . . . . Craig Expires - November 8, 2006 [Page 26] Internet-Draft M2PA Implementer's Guide May 8, 2006 . LS PR-------------------------------> . . . . . Cancel RPO . . X<-------------------------LS Ready (1) . . . . . . . . . . . T4 expires . . . . . Start T1 . . <-------------------------LS Ready (0) . . . . . L2L3INS-----> . . . . In Service . <----L2L3INS . . . . . In Service . . . . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . Figure 4. Aligned Not Ready Example 3 for [T1.111] Variant 2.8.7. PO Example (Clear Buffers) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset and abatement of local processor outage while the link is in service. This example assumes that MTP3 issues the Clear Buffers primitive and that no User Data messages are transmitted during the period depicted. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . In Service . . In Service . . . . . . . {MGMTL2LPO}---> . . . . . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . . . . LS PO-------------------------------> . . . . . . . . . . . L2L3RPO-----> . . . . Mark RPO . . . . . Processor . . . . . Outage . . . . . . . Craig Expires - November 8, 2006 [Page 27] Internet-Draft M2PA Implementer's Guide May 8, 2006 Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . . . . . . . <--L3L2CLRRTB . . . . L2L3RTBCLRD-> . <------------------------LS Ready (1) . . . . . In Service . . . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . <-L2L3RTBCLRD . . . . . LS Ready (1)------------------------>X . . In Service . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . . Figure 5. PO Example (Clear Buffers) [T1.111] Variant 2.8.8. PO Example (Resume) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset and abatement of local processor outage while the link is in service. This example assumes that MTP3 issues a resume primitive. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . Craig Expires - November 8, 2006 [Page 28] Internet-Draft M2PA Implementer's Guide May 8, 2006 . In Service . . In Service . . . . . . . {MGMTL2LPO}---> . . . . . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . . . . LS PO-------------------------------> . . . . . . . . . . . L2L3RPO-----> . . . . Processor . . . . . Outage . . . . . Mark RPO . . . . . . . Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2RESUME--> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . . . L3L2TXMSU---> . . . . . . . . . . . . . . <--L3L2RESUME . <------------------------LS Ready (1) . . . . . In Service . . . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . <---L3L2TXMSU . . . . . . . <---------------------------User Data . . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . . LS Ready (1)------------------------>X . . In Service . . . . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked Craig Expires - November 8, 2006 [Page 29] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . . . . User Data---------------------------> . . . . . . . Figure 6. PO Example (Clear Buffers) [T1.111] Variant 2.8.9. PO Example (Synchronization) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset and abatement of local processor outage while the link is in service. This example assumes that MTP3 issues the Clear Buffers primitive, and the example provides details depicting sequence number synchronization. A B ---------------------------- ---------------------------- MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- TB=none TB=none RTB=none RTB=none PO_RB=none PO_RB=none Last_FSN=0 Last_FSN=10 Next_BSN=10 Next_BSN=0 . . . . . . . In Service . . In Service . . . . . . . L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU TB=1,2,3,4,5,6 TB=11,12,13,14,15,16 RTB=none RTB=none PO_RB=none PO_RB=none Last_FSN=6 Last_FSN=16 Next_BSN=10 Next_BSN=0 . . . . . . . User Data FSN=1 BSN=10--------------> . . User Data FSN=2 BSN=10--------------> . . User Data FSN=3 BSN=10--------------> . . <--------------User Data FSN=11 BSN=0 . . <--------------User Data FSN=12 BSN=0 . . <--------------User Data FSN=13 BSN=0 . Craig Expires - November 8, 2006 [Page 30] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . . . <-L2L3RXMSU(11) . . . . <-L2L3RXMSU(12) . . . . <-L2L3RXMSU(13) . . . . . . . . . . TB=4,5,6 TB=14,15,16 RTB=1,2,3 RTB=11,12,13 PO_RB=none PO_RB=none Last_FSN=6 Last_FSN=16 Next_BSN=13 Next_BSN=0 . . . . . . {MGMTL2LPO}---> . . . . . . . . . . Unavailable . . . . Available Aligned . . . . Aligned Blocked . . . . Not Blocked . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . . . . User Data FSN=4 BSN=13--------------> . . User Data FSN=5 BSN=13--------------> . . User Data FSN=6 BSN=13--------------> . . . . . . . . LS PO FSN=3 BSN=13------> . . . . . . . . . . . . L2L3RXMSU(1)-> . . . . L2L3RXMSU(2)-> . . . . L2L3RXMSU(3)-> . . . . . . . <--------------User Data FSN=14 BSN=3 . . <--------------User Data FSN=15 BSN=3 . . <--------------User Data FSN=16 BSN=3 . . . . . . . TB=4,5,6 TB=none RTB=none RTB=14,15,16 PO_RB=14,15,16 PO_RB=none Last_FSN=6 Last_FSN=16 Next_BSN=13 Next_BSN=3 . . . . . . . . LS PO FSN=3 BSN=13------> . . . . . . . . . . . L2L3RXMSU(4)-> . . . . L2L3RXMSU(5)-> . . . . L2L3RXMSU(6)-> Craig Expires - November 8, 2006 [Page 31] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . . . . . . . L2L3RPO-----> . . . . Processor . . . . . Outage . . . . . Mark RPO . . . . . . . . . . . . Unavailable . . . . . Aligned . . . . . Blocked . . . . . . While in LPO, (A) must buffer messages 14-16 without acknowledging them. . . . . . . . <--------Empty User Data FSN=16 BSN=6 . . . . . . . TB=none TB=none RTB=none RTB=14,15,16 PO_RB=14,15,16 PO_RB=none Last_FSN=6 Last_FSN=16 Next_BSN=13 Next_BSN=6 . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . . . . . . LPO ends at (A). (A) M2PA clears its PO_RB, TB, and RTB, but does not notify its MTP3 of clear completion. This prevents(A) MTP3 from delivering new MSUs for transmission until sequence number synchronization is complete. TB=none TB=none RTB=none RTB=14,15,16 PO_RB=none PO_RB=none Last_FSN=6 Last_FSN=16 Next_BSN=13 Next_BSN=6 . . . . . . . LS PR FSN=6 BSN=13------------------> . . . . . . . Unavailable . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . Craig Expires - November 8, 2006 [Page 32] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . L2L3RPR-----> . . . . . . . . . . <--L3L2CLRRTB . . . . L2L3RTBCLRD-> . <---------------LS Ready FSN=13 BSN=6 . . . . . In Service . . . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . <-L2L3RTBCLRD . . . . . LS Ready FSN=6 BSN=13--------------->X . . In Service . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . . (B) M2PA receives LS PR, uses the BSN to reset its Last FSN and notifies its MTP3. (B) MTP3 sends a Clear RTB primitive to M2PA, and M2PA clears its RTB and PO_RB. Upon completion of the clear, (B) M2PA notifies MTP3 and sends a synchronization LS Ready on the User Data stream. (A) receives the LS Ready, uses the BSN to reset its Last FSN, and then notifies its MTP3. (A) M2PA sends a LS Ready message on the User Data stream, and (B) M2PA receives it and ignores it. The peer sequence numbers are synchronized, and both peers are in service. TB=none TB=none RTB=none RTB=none PO_RB=none PO_RB=none Last_FSN=6 Last_FSN=13 Next_BSN=13 Next_BSN=6 . . . . . . L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU L3L2TXMSU---> . . <---L3L2TXMSU . . . . . . . User Data FSN=7 BSN=13--------------> . . <--------------User Data FSN=14 BSN=6 . . . . . . . <-L2L3RXMSU(14) . . L2L3RXMSU(7)-> . . . . . . Craig Expires - November 8, 2006 [Page 33] Internet-Draft M2PA Implementer's Guide May 8, 2006 . User Data FSN=8 BSN=14--------------> . . <--------------User Data FSN=15 BSN=7 . . . . . . . <-L2L3RXMSU(15) . . L2L3RXMSU(8)-> . . . . . . . User Data FSN=9 BSN=15--------------> . . <--------------User Data FSN=16 BSN=8 . . . . . . . <-L2L3RXMSU(16) . . L2L3RXMSU(9)-> . . . . . . . Empty User Data FSN=9 BSN=16--------> . . <--------Empty User Data FSN=16 BSN=9 . . . . . . . Figure 7. PO Example (Synchronization) [T1.111] Variant 2.8.10. PO Example (LPO and RPO onset) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the nearly simultaneous onset of local processor outage on each peer while the link is in service. The processor outage condition clears only on the left side. This example assumes that MTP3 issues the Clear Buffers primitive. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . In Service . . In Service . . . . . . . {MGMTL2LPO}---> . . . . . . . . <---{MGMTL2LPO} . Mark LPO . . . . . Processor . . . . . Outage . . . . . LS PO-------------------------------> . . . . . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . <-------------------------------LS PO . . . . . . . . . . . Mark RPO . . . . . L2L3RPO-----> . . . . . . Craig Expires - November 8, 2006 [Page 34] Internet-Draft M2PA Implementer's Guide May 8, 2006 . Mark RPO . . . . <-----L2L3RPO . . . . . . . . . . Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . Synch FSN . . . . . Cancel RPO . . . . . L2L3RPR-----> . <------------------------LS Ready (1) . . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . <-L2L3RTBCLRD . . . . . LS Ready (1)------------------------>X . . . . . . . . . . . <-L3L2CLRBFRS . . . . Cancel LPO . . . . . Start Tsync . . <-------------------------------LS PR . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . <-----L2L3RPR . . . . . LS Ready (1)------------------------> . . In Service . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . . . . . . Stop Tsync . . . . . Synch FSN . . . . . L2L3RPR-----> . X<------------------------LS Ready (1) . . . . . In Service . . . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . Figure 8. PO Example (LPO and RPO onset) [T1.111] Variant Craig Expires - November 8, 2006 [Page 35] Internet-Draft M2PA Implementer's Guide May 8, 2006 2.8.11. PO Example (LPO and RPO abate) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the nearly simultaneous onset and abtement of local processor outage on each peer while the link is in service. This example assumes that MTP3 issues the Clear Buffers primitive. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . In Service . . In Service . . . . . . . {MGMTL2LPO}---> . . . . . . . . <---{MGMTL2LPO} . Mark LPO . . . . . Processor . . . . . Outage . . . . . LS PO-------------------------------> . . . . . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . <-------------------------------LS PO . . . . . . . . . . . Mark RPO . . . . . L2L3RPO-----> . . . . . . . Mark RPO . . . . <-----L2L3RPO . . . . . . . . . . Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2CLRBFRS-> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . <-L3L2CLRBFRS . . . . Cancel LPO . . . . . Start Tsync . . <-------------------------------LS PR . . . . . . . Craig Expires - November 8, 2006 [Page 36] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . Stop Tsync . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . L2L3BFRSCLD-> . . <<-----------LS Ready (1) . . . . . In Service . . Stop Tsync . . . . . Cancel RPO . . . . . Cancel LPO . . . . . Synch FSN . . . . <-----L2L3RPR . . . . <-L2L3RTBCLRD . . . . . LS Ready (1)----------->> . . . In Service . . . . . . . . . . . X<--LS Ready (1) . . . . . . . . . . . . LS Ready (1)-->X . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . Figure 9. PO Example (LPO and RPO abate) [T1.111] Variant 2.8.12. L2 Busy Example (Simple) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of a local busy condition on one peer. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . . In Service . . In Service . . Not Local Busy . . Not Remote Busy . . . . . . . . <---------------------------User Data . . . . . Start T7 . . . . . . . . {Local Busy Onset} . . . . . Mark Local Busy . . . . . LS Busy-----------------------------> . . . . . . . . . . . Mark Remote Busy . . . . . Stop T7 . Craig Expires - November 8, 2006 [Page 37] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . Start T6 . . . . . . . L3L2TXMSU---> . . . . . . . . . . . User Data---------------------------> . . Start T7 . . . . . . . . L2L3RXMSU---> . . . . . . . . . . <---L3L2TXMSU . . . . . . . <---------------------Empty User Data . . Stop T7 . . . . . . . . . . . {Local Busy Abate} . . . . . Cancel Local Busy . . . . . LS Busy Ended-----------------------> . <---L2L3RXMSU . . . . . . . . . . . . . . Cancel Remote Busy . . . . . Stop T6 . . . . . Start T7 . . . . . . . . Empty User Data---------------------> . . . . . . . . . . . Stop T7 . . . . . . . . <---------------------------User Data . . . . . Start T7 . . . . . . . <---L2L3RXMSU . . . . . . . . . . . Empty User Data---------------------> . . . . . . . . . . . Stop T7 . . . . . . . Figure 10. L2 Busy Example (One Side, Simple) [T1.111] Variant 2.8.13. L2 Busy Example (With FSN) [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of a local busy condition on one peer and highlights the buffering of received non-empty User Data. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Craig Expires - November 8, 2006 [Page 38] Internet-Draft M2PA Implementer's Guide May 8, 2006 . In Service . . In Service . . Not Local Busy . . Not Remote Busy . . . . . . . TB=none TB=none RTB=none RTB=none Busy_RB=none Busy RB=none Last_FSN=0 Last_FSN=10 Next_BSN=10 Next_BSN=0 . . . . . . L3L2TXMSU---> . . <---L3L2TXMSU . . . . <---L3L2TXMSU . . . . <---L3L2TXMSU . . . . . . . User Data FSN=1 BSN=10--------------> . . Start T7 . . . . . . . . . . . <--------------User Data FSN=11 BSN=0 . . . . . Start T7 . . . . . . . <-L2L3RXMSU(11) . . . . . . . . L2L3RXMSU(1)-> . . . . . . . {Local Busy Onset} . . . . . Mark Local Busy . . . . . LS Busy-----------------------------> . . . . . . . . <--------------User Data FSN=12 BSN=1 . . Stop T7 . . . . . . . . . . . . . . . . . <--------------User Data FSN=13 BSN=1 . . . . . . . TB=none TB=none RTB=none RTB=12,13 Busy_RB=12,13 Busy RB=none Last_FSN=2 Last_FSN=13 Next_BSN=11 Next_BSN=2 . . . . . . . . . . Mark Remote Busy . . . . . Stop T7 . . . . . Start T6 . . . . . . . . . . . <---L3L2TXMSU . . . . . . L3L2TXMSU---> . . . . Craig Expires - November 8, 2006 [Page 39] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . . . . User Data FSN=2 BSN=11--------------> . . Start T7 . . . . . . . . L2L3RXMSU(2)--> . . . . . . . . . . <---L3L2TXMSU . . . . . . . <--------Empty User Data FSN=13 BSN=2 . . Stop T7 . . . . . . . . . . TB=none TB=two RTB=none RTB=12,13 Busy_RB=12,13 Busy RB=none Last_FSN=2 Last_FSN=13 Next_BSN=11 Next_BSN=2 . . . . . . . {Local Busy Abate} . . . . . Cancel Local Busy . . . . . LS Busy Ended-----------------------> . <-L2L3RXMSU(12) . . . . <-L2L3RXMSU(13) . . . . . . . . . . . . . . Cancel Remote Busy . . . . . Stop T6 . . . . . Start T7 . . . . . . . . Empty User Data FSN=2 BSN=13--------> . . . . . . . . . . . Stop T7 . . . . . . . . <--------------User Data FSN=14 BSN=2 . . . . . Start T7 . . . . . . . . <--------------User Data FSN=15 BSN=2 . . . . . . . <-L2L3RXMSU(14) . . . . <-L2L3RXMSU(15) . . . . . . . . . . . Empty User Data FSN=2 BSN=15--------> . . . . . . . . . . . Stop T7 . . . . . . . Figure 11. L2 Busy Example (One Side, With Data) [T1.111] Variant Craig Expires - November 8, 2006 [Page 40] Internet-Draft M2PA Implementer's Guide May 8, 2006 2.8.14. Simultaneous Busy and PO Example [T1.111] Variant This example is for a [T1.111] variant M2PA and depicts the onset of local congestion, followed by the onset of local processor outage, then the abatement of local processor outage, and finally the abatement of local busy, all occurring while the link is in service. This example assumes that MTP3 issues the Resume primitive, and that timer T6 does not expire. MTP3 M2PA SCTP SCTP M2PA MTP3 ---- ---- ---- ---- ---- ---- . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . In Service . . In Service . . Not Local Busy . . Not Remote Busy . . . . . . . . . . . <---L3L2TXMSU . . . . . . . <---------------------------User Data . . . . . Start T7 . . . . . . . . {Local Busy Onset} . . . . . Mark Local Busy . . . . . Start T5 . . . . . LS Busy-----------------------------> . . . . . . . . . . . Mark Remote Busy . . . . . Stop T7 . . . . . Start T6 . . . . . . . {MGMTL2LPO}---> . . . . . . . . . . . Mark LPO . . . . . Processor . . . . . Outage . . . . . LS PO-------------------------------> . . . . . . . . . . . L2L3RPO-----> . . . . Processor . . . . . Outage . . . . . Mark RPO . . . . . . . . T5 Expiry . . . . . Start T5 . . . . . LS Busy----------------------------->X . . . . . . . Craig Expires - November 8, 2006 [Page 41] Internet-Draft M2PA Implementer's Guide May 8, 2006 Unavailable . . . . Unavailable Aligned . . . . Aligned Blocked . . . . Blocked . . . . . . L3L2RESUME--> . . . . . Start Tsync . . . . . LS PR-------------------------------> . . . . . . . . . . . Cancel RPO . . . . . Synch FSN . . . . . L2L3RPR-----> . . . . . . L3L2TXMSU---> . . . . . . . . . . . . . . <--L3L2RESUME . <------------------------LS Ready (1) . . . . . In Service . . . . . . . . . . . . Available . . . . . Aligned . . . . . Not Blocked . . . . . . . . . . <---L3L2TXMSU . . . . . . . Stop Tsync . . . . . Cancel LPO . . . . . Synch FSN . . . . . LS Ready (1)------------------------>X . . In Service . . . . . . . . . . Available . . . . Available Aligned . . . . Aligned Not Blocked . . . . Not Blocked . . . . . . . User Data---------------------------> . . Start T7 . . . . . . . . . . . . . . L2L3RXMSU---> . . . . . . . <---------------------Empty User Data . . . . . . . . Stop T7 . . . . . . . . . . . {Local Busy Abate} . . . . . Cancel Local Busy . . . . . LS Busy Ended-----------------------> . <---L2L3RXMSU . . . . . . . . . . . . . . Cancel Remote Busy . Craig Expires - November 8, 2006 [Page 42] Internet-Draft M2PA Implementer's Guide May 8, 2006 . . . . Stop T6 . . . . . Start T7 . . . . . . . . Empty User Data---------------------> . . . . . . . . . . . Stop T7 . . . . . . . . <---------------------------User Data . . . . . Start T7 . . . . . . . Figure 12. Simultaneous Busy and PO Example [T1.111] Variant 3. Security Considerations No new threats have been identified in M2PA [RFC4165]. 4. Acknowledgments The author thanks Mark Davidson and many others for their invaluable comments. 5. References [RFC4165] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H., Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", RFC 4165, September 2005. [Q.703] ITU, "Signaling System No. 7 - Signaling Link," ITU-T Recommendation Q.703, ITU-T Telecommunication Standardization Sector of ITU (July 1996). [Q.2140] ITU, "B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for Signaling at the Network Node Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T Telecommunication Standardization Sector of ITU (February 1995). [T1.111] ANSI, "American National Standard for Telecommunications - Signaling System Number 7 (SS7) - Message Transfer Part (MTP)," ANSI T1.111-2001, American National Standards Institute (February 2001). Craig Expires - November 8, 2006 [Page 43] Internet-Draft M2PA Implementer's Guide May 8, 2006 Appendix A. Changes Control +---------+---------------------------------------------------------+ | Version | Summary of Changes | +---------+---------------------------------------------------------+ | 00 | Document created. | +---------+---------------------------------------------------------+ Author's Address Jeffrey Craig Tekelec Inc. 5200 Paramount Parkway Phone: 1-919-380-3870 Morrisville, NC USA 27560 Email: jeffrey.craig@tekelec.com Craig Expires - November 8, 2006 [Page 44] Internet-Draft M2PA Implementer's Guide May 8, 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Craig Expires - November 8, 2006 [Page 45]