Internet DRAFT - draft-craig-sigtran-m2pa-ig

draft-craig-sigtran-m2pa-ig







Signaling Transport Working Group                               J. Craig
Internet Draft                                                   Tekelec
Expires: November 8, 2006                                    May 8, 2006


                         M2PA Implementer's guide
                   <draft-craig-sigtran-m2pa-ig-00.txt>

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]