doc: Add RFC documents

1 files changed, 2971 insertions, 0 deletions

diff --git a/doc/rfc/rfc4165.txt b/doc/rfc/rfc4165.txt
new file mode 100644
index 0000000..8075c11
--- /dev/null
+++ b/doc/rfc/rfc4165.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                       T. George
+Request for Comments: 4165                                B. Bidulock
+Category: Standards Track                                     OpenSS7
+                                                             R. Dantu
+                                            University of North Texas
+                                                      H. Schwarzbauer
+                                                              Siemens
+                                                         K. Morneault
+                                                        Cisco Systems
+                                                       September 2005
+
+
+       Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
+               User Peer-to-Peer Adaptation Layer (M2PA)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a protocol supporting the transport of
+   Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
+   signaling messages over Internet Protocol (IP) using the services of
+   the Stream Control Transmission Protocol (SCTP).  This protocol would
+   be used between SS7 Signaling Points using the MTP Level 3 protocol.
+   The SS7 Signaling Points may also use standard SS7 links using the
+   SS7 MTP Level 2 to provide transport of MTP Level 3 signaling
+   messages.  The protocol operates in a manner similar to MTP Level 2
+   so as to provide peer-to-peer communication between SS7 endpoints.
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 1]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Scope ......................................................3
+      1.2. Terminology ................................................3
+      1.3. Abbreviations ..............................................4
+      1.4. Conventions ................................................5
+      1.5. Signaling Transport Architecture ...........................5
+      1.6. Services Provided by M2PA ..................................7
+      1.7. Functions Provided by M2PA .................................9
+      1.8. Definition of the M2PA Boundaries .........................10
+      1.9. Differences Between M2PA and M2UA .........................10
+   2. Protocol Elements ..............................................12
+      2.1. Common Message Header .....................................12
+      2.2. M2PA Header ...............................................13
+      2.3. M2PA Messages .............................................14
+   3. State Control ..................................................17
+      3.1. SCTP Association State Control ............................17
+      3.2. M2PA Link State Control ...................................18
+   4. Procedures .....................................................19
+      4.1. Procedures to Support MTP2 Features .......................19
+      4.2. Procedures to Support the MTP3/MTP2 Interface .............30
+      4.3. SCTP Considerations .......................................33
+   5. Examples of M2PA Procedures ....................................34
+      5.1. Link Initialization (Alignment) ...........................34
+      5.2. Message Transmission and Reception ........................37
+      5.3. Link Status Indication ....................................37
+      5.4. Link Status Message (Processor Outage) ....................38
+      5.5. Level 2 Flow Control ......................................42
+      5.6. MTP3 Signaling Link Congestion ............................44
+      5.7. Link Deactivation .........................................45
+      5.8. Link Changeover ...........................................45
+   6. Security Considerations ........................................47
+   7. IANA Considerations ............................................47
+      7.1. SCTP Payload Protocol Identifier ..........................47
+      7.2. M2PA Protocol Extensions ..................................48
+   8. Acknowledgements ...............................................49
+   9. References .....................................................50
+      9.1. Normative References ......................................50
+      9.2. Informative References ....................................51
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 2]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+1.  Introduction
+
+1.1.  Scope
+
+   There is a need for Switched Circuit Network (SCN) signaling protocol
+   delivery over an IP network.  This includes message transfer between
+   the following:
+
+      - a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
+        [RFC2719]
+
+      - a SG and an IP Signaling Point (IPSP)
+
+      - an IPSP and an IPSP
+
+   This could allow for convergence of some signaling and data networks.
+   SCN signaling nodes would have access to databases and other devices
+   in the IP network domain that do not use SS7 signaling links.
+   Likewise, IP telephony applications would have access to SS7
+   services.  There may also be operational cost and performance
+   advantages when traditional signaling links are replaced by IP
+   network "connections".
+
+   The delivery mechanism described in this document allows for full
+   MTP3 message handling and network management capabilities between any
+   two SS7 nodes communicating over an IP network.  An SS7 node equipped
+   with an IP network connection is called an IP Signaling Point (IPSP).
+   The IPSPs function as traditional SS7 nodes using the IP network
+   instead of SS7 links.
+
+   The delivery mechanism should:
+
+      - Support seamless operation of MTP3 protocol peers over an IP
+        network connection.
+
+      - Support the MTP Level 2 / MTP Level 3 interface boundary.
+
+      - Support management of SCTP transport associations and traffic
+        instead of MTP2 Links.
+
+      - Support asynchronous reporting of status changes to management.
+
+1.2.  Terminology
+
+   MTP  - The Message Transfer Part of the SS7 protocol [Q.700] [Q.701]
+   [Q.702] [Q.703] [Q.704] [Q.705] [T1.111].
+
+   MTP2 - MTP Level 2, the MTP signaling link layer.
+
+
+
+George, et al.              Standards Track                     [Page 3]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   MTP3 - MTP Level 3, the MTP signaling network layer.
+
+   MTP2-User - A protocol that normally uses the services of MTP Level
+   2.  The only MTP2 user is MTP3.  The MTP2 user is equivalent to the
+   M2PA user.
+
+   Signaling End Point (SEP) - An SS7 Signaling Point that originates or
+   terminates signaling messages.  One example is a central office
+   switch.  [RFC2719]
+
+   IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP network
+   connection used for SS7 over IP.
+
+   Signaling Gateway (SG) - A signaling agent that receives/sends SCN
+   native signaling at the edge of the IP network [RFC2719].  In this
+   context, an SG is an SS7 Signaling Point that has both an IP network
+   connection used for SS7 over IP, and a traditional (non-IP) link to
+   an SS7 network.
+
+   Signal Transfer Point (STP) - A Signal Transfer Point as defined by
+   MTP standards, e.g., [Q.700].
+
+   Signaling Point (STP) - A Signaling Point as defined by MTP
+   standards, e.g., [Q.700].
+
+   Association - An association refers to an SCTP association [RFC2960].
+   The association provides the transport for MTP3 protocol data units
+   and M2PA adaptation layer peer messages.
+
+   Network Byte Order - Most significant byte first, also known as "Big
+   Endian".  See [RFC791], Appendix B "Data Transmission Order".
+
+   Stream - A stream refers to an SCTP stream [RFC2960].
+
+1.3.  Abbreviations
+
+   BSNT   - Backward Sequence Number to be Transmitted
+
+   FSNC   - Forward Sequence Number of last message accepted by remote
+            level 2
+
+   LI     - Length Indicator
+
+   MSU    - Message Signal Unit
+
+   SCCP   - Signaling Connection Control Part
+
+   SCN    - Switched Circuit Network
+
+
+
+George, et al.              Standards Track                     [Page 4]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   SCTP   - Stream Control Transmission Protocol
+
+   SIF    - Signaling Information Field
+
+   SIO    - Service Information Octet
+
+   SLC    - Signaling Link Code
+
+   SS7    - Signaling System Number 7
+
+   SSN    - Stream Sequence Number
+
+   STP    - Signal Transfer Point
+
+1.4.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.5.  Signaling Transport Architecture
+
+   The architecture that has been defined [RFC2719] for Switched Circuit
+   Network (SCN) signaling transport over IP uses multiple components,
+   including an IP transport protocol, the Stream Control Transmission
+   Protocol (SCTP), and an adaptation module to support the services
+   expected by a particular SCN signaling protocol from its underlying
+   protocol layer.
+
+   Within this framework architecture, this document defines an SCN
+   adaptation module that is suitable for the transport of SS7 MTP3
+   messages.  The adaptation layer, known as the MTP2 User Peer-to-peer
+   Adaptation Layer (M2PA), provides MTP3 with an interface and services
+   similar to MTP2.  In effect, MTP2 and lower layers of the traditional
+   SS7 protocol stack are replaced by an IP equivalent.
+
+   Figure 1 shows the seamless interworking at the MTP3 layer.  MTP3 is
+   adapted to the SCTP layer using the MTP2 User Peer-to-peer Adaptation
+   Layer (M2PA).  All the primitives between MTP3 and MTP2 are supported
+   by M2PA.  The SCTP association acts as one SS7 link between the
+   IPSPs.  An IPSP may have the Signaling Connection Control Part (SCCP)
+   and other SS7 layers above MTP3.
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 5]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+               ********   IP   ********
+               * IPSP *--------* IPSP *
+               ********        ********
+
+               +------+        +------+
+               | TCAP |        | TCAP |
+               +------+        +------+
+               | SCCP |        | SCCP |
+               +------+        +------+
+               | MTP3 |        | MTP3 |
+               +------+        +------+
+               | M2PA |        | M2PA |
+               +------+        +------+
+               | SCTP |        | SCTP |
+               +------+        +------+
+               | IP   |        | IP   |
+               +------+        +------+
+
+        IP    - Internet Protocol
+        IPSP  - IP Signaling Point
+        SCTP  - Stream Control Transmission Protocol [RFC2960]
+
+        Figure 1.  M2PA Symmetrical Peer-to-Peer Architecture
+
+   Figure 2 shows an example of M2PA used in a Signaling Gateway (SG).
+   The SG is an IPSP that is equipped with both traditional SS7 and IP
+   network connections.
+
+   The SEP and the SG communicate through a traditional SS7 link, which
+   follows a protocol such as [Q.702].  The SG and the IPSP communicate
+   through an IP link using the M2PA protocol.  Messages sent from the
+   SEP to the IPSP (and vice versa) are routed by the SG.
+
+   Any of the nodes in the diagram could have SCCP or other SS7 layers
+   above MTP3.  The Signaling Gateway acts as a Signal Transfer Point
+   (STP).  Other STPs MAY be present in the SS7 path between the SEP and
+   the SG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 6]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+       ********  SS7   ***************   IP   ********
+       * SEP  *--------*     SG      *--------* IPSP *
+       ********        ***************        ********
+
+       +------+                               +------+
+       | TCAP |                               | TCAP |
+       +------+                               +------+
+       | SCCP |                               | SCCP |
+       +------+        +-------------+        +------+
+       | MTP3 |        |    MTP3     |        | MTP3 |
+       +------+        +------+------+        +------+
+       | MTP2 |        | MTP2 | M2PA |        | M2PA |
+       |      |        |      +------+        +------+
+       |      |        |      | SCTP |        | SCTP |
+       +------+        +------+------+        +------+
+       | MTP1 |        | MTP1 | IP   |        | IP   |
+       +------+        +------+------+        +------+
+
+        SEP   - SS7 Signaling Endpoint
+
+            Figure 2.  M2PA in IP Signaling Gateway
+
+   Figure 2 is only an example.  Other configurations are possible.  In
+   short, M2PA uses the SCTP association as an SS7 link.  The
+   M2PA/SCTP/IP stack can be used in place of an MTP2/MTP1 stack.
+
+1.5.1.  Point Code Representation
+
+   MTP requires that each node with an MTP3 layer is identified by an
+   SS7 point code.  In particular, each IPSP MUST have its own SS7 point
+   code.
+
+1.6.  Services Provided by M2PA
+
+   The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP.  The
+   M2PA protocol layer is required to provide a set of services to its
+   user equivalent to that provided by MTP Level 2 to MTP Level 3.
+
+   These services are described in the following subsections.
+
+1.6.1.  Support for MTP Level 2 / MTP Level 3 Interface Boundary
+
+   This interface is the same as the MTP2/MTP3 interface described in
+   the applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140], with
+   the addition of support for the larger sequence numbers found in
+   [T1.111] and [Q.2210].
+
+
+
+
+
+George, et al.              Standards Track                     [Page 7]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   M2PA receives the primitives sent from MTP3 to its lower layer.  M2PA
+   processes these primitives or maps them to appropriate primitives at
+   the M2PA/SCTP interface.  Likewise, M2PA sends primitives to MTP3
+   similar to those used in the MTP3/MTP2 interface.
+
+   Because M2PA uses larger sequence numbers than MTP2, the MTP3
+   Changeover procedure MUST use the Extended Changeover Order and
+   Extended Changeover Acknowledgement messages described in [Q.2210]
+   and [T1.111].
+
+   Also, the following MTP3/MTP2 primitives must use the larger sequence
+   numbers:
+
+      - BSNT Confirmation
+
+      - Retrieval Request and FSNC
+
+1.6.2.  Support for Peer-to-Peer Communication
+
+   In SS7, MTP Level 2 sends three types of messages, known as signal
+   units: Message Signal Units (MSUs), Link Status Signal Units (LSSUs),
+   and Fill-In Signal Units (FISUs).
+
+   MSUs originate at a higher level than MTP2, and are destined for a
+   peer at another node.  Likewise, M2PA passes these messages from MTP3
+   to SCTP as data for transport across a link.  These are called User
+   Data messages in M2PA.
+
+   LSSUs allow peer MTP2 layers to exchange status information.
+   Analogous messages are needed for M2PA.  The Link Status message
+   serves this purpose.
+
+   FISUs are transmitted continuously when no other signal units are
+   waiting to be sent.  FISUs also carry acknowledgement of messages.
+   Since an IP network is a shared resource, it would be undesirable to
+   have a message type that is sent continuously as is the case with
+   FISUs.  Furthermore, SCTP does not require its upper layer to
+   continuously transmit messages.  Therefore, M2PA does not provide a
+   protocol data unit like the FISU.  The M2PA User Data message is used
+   to carry acknowledgement of messages.  If M2PA needs to acknowledge a
+   message, and it has no MTP3 message of its own to send, an empty User
+   Data message can be sent.
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 8]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+1.7.  Functions Provided by M2PA
+
+1.7.1.  MTP2 Functionality
+
+   M2PA provides MTP2 functionality that is not provided by SCTP; thus,
+   together M2PA and SCTP provide functionality similar to that of MTP2.
+
+   SCTP provides reliable, sequenced delivery of messages.
+
+   M2PA functionality includes:
+
+      - Data retrieval to support the MTP3 changeover procedure
+
+      - Reporting of link status changes to MTP3
+
+      - Processor outage procedure
+
+      - Link alignment procedure
+
+1.7.2.  Mapping of SS7 and IP Entities
+
+   The M2PA layer must maintain a map of each of its SS7 links to the
+   corresponding SCTP association.
+
+1.7.3.  SCTP Association Management
+
+   SCTP allows a user-specified number of streams to be opened during
+   the initialization.  It is the responsibility of the M2PA layer to
+   ensure proper management of the streams allowed within each
+   association.
+
+   M2PA uses two streams in each direction for each association.  Stream
+   0 in each direction is designated for Link Status messages.  Stream 1
+   is designated for User Data messages, as well as Link Status messages
+   that must remain in sequence with the User Data messages.  Separating
+   the Link Status and User Data messages into separate streams allows
+   M2PA to prioritize the messages in a manner similar to MTP2.
+
+   Notifications received from SCTP are processed by M2PA or translated
+   into an appropriate notification to be sent to the upper layer MTP3.
+
+1.7.4.  Retention of MTP3 in the SS7 Network
+
+   M2PA allows MTP3 to perform all of its Message Handling and Network
+   Management functions with IPSPs as it does with other SS7 nodes.
+
+
+
+
+
+
+George, et al.              Standards Track                     [Page 9]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+1.8.  Definition of the M2PA Boundaries
+
+1.8.1.  Definition of the M2PA / MTP Level 3 Boundary
+
+   The upper layer primitives provided by M2PA are the same as those
+   provided by MTP2 to MTP3.  These primitives are described in the
+   applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140].
+
+1.8.2.  Definition of the Lower Layer Boundary between M2PA and SCTP
+
+   The upper layer primitives provided by SCTP are described in
+   [RFC2960] Section 10 "Interface with Upper Layer".
+
+1.9.  Differences Between M2PA and M2UA
+
+   The MTP2 User Adaptation Layer (M2UA) [M2UA] also adapts the MTP3
+   layer to the SCTP/IP stack.  It does so through a backhauling
+   architecture [RFC2719].  This section is intended to clarify some of
+   the differences between the M2PA and M2UA approaches.
+
+   A possible M2PA architecture is shown in Figure 3.  Here the IPSP's
+   MTP3 uses its underlying M2PA as a replacement for MTP2.
+   Communication between the two layers MTP3/M2PA is defined by the same
+   primitives as in SS7 MTP3/MTP2.  M2PA performs functions similar to
+   MTP2.
+
+       ********  SS7   ***************   IP   ********
+       * SEP  *--------*     SG      *--------* IPSP *
+       ********        ***************        ********
+
+       +------+        +-------------+        +------+
+       | SCCP |        |    SCCP     |        | SCCP |
+       +------+        +-------------+        +------+
+       | MTP3 |        |    MTP3     |        | MTP3 |
+       +------+        +------+------+        +------+
+       | MTP2 |        | MTP2 | M2PA |        | M2PA |
+       |      |        |      +------+        +------+
+       |      |        |      | SCTP |        | SCTP |
+       +------+        +------+------+        +------+
+       | MTP1 |        | MTP1 | IP   |        | IP   |
+       +------+        +------+------+        +------+
+
+                  Figure 3.  M2PA in IP Signaling Gateway
+
+   A comparable architecture for M2UA is shown in Figure 4.  In M2UA,
+   the MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer.  Likewise,
+   the SG's MTP2 uses the MGC's MTP3 as its upper SS7 layer.  In SS7,
+
+
+
+
+George, et al.              Standards Track                    [Page 10]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   communication between the MTP3 and MTP2 layers is defined by
+   primitives.  In M2UA, the MTP3/MTP2 communication is defined as M2UA
+   messages and sent over the IP connection.
+
+       ********  SS7   ***************   IP   ********
+       * SEP  *--------*     SG      *--------* MGC  *
+       ********        ***************        ********
+
+       +------+                               +------+
+       | SCCP |                               | SCCP |
+       +------+                               +------+
+       | MTP3 |             (NIF)             | MTP3 |
+       +------+        +------+------+        +------+
+       | MTP2 |        | MTP2 | M2UA |        | M2UA |
+       |      |        |      +------+        +------+
+       |      |        |      | SCTP |        | SCTP |
+       +------+        +------+------+        +------+
+       | MTP1 |        | MTP1 | IP   |        | IP   |
+       +------+        +------+------+        +------+
+
+        NIF   - Nodal Interworking Function
+
+                  Figure 4.  M2UA in IP Signaling Gateway
+
+   M2PA and M2UA are similar in that:
+
+      a. Both transport MTP3 data messages.
+
+      b. Both present an MTP2 upper interface to MTP3.
+
+   Differences between M2PA and M2UA include:
+
+      a. M2PA: IPSP processes MTP3/MTP2 primitives.
+         M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
+               and the MGC's MTP3 (via the NIF) for processing.
+
+      b. M2PA: SG-IPSP connection is an SS7 link.
+         M2UA: SG-MGC connection is not an SS7 link.  It is an
+               extension of MTP to a remote entity.
+
+      c. M2PA: SG is an SS7 node with a point code.
+         M2UA: SG is not an SS7 node and has no point code.
+
+      d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
+         M2UA: SG does not have upper SS7 layers since it has no MTP3.
+
+      e. M2PA: relies on MTP3 for management procedures.
+         M2UA: uses M2UA management procedures.
+
+
+
+George, et al.              Standards Track                    [Page 11]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   Potential users of M2PA and M2UA should be aware of these differences
+   when deciding how to use them for SS7 signaling transport over IP
+   networks.
+
+2.  Protocol Elements
+
+   This section describes the format of various messages used in this
+   protocol.
+
+   All fields in an M2PA message must be transmitted in the network byte
+   order, i.e., most significant byte first, unless otherwise stated.
+
+2.1.  Common Message Header
+
+   The protocol messages for M2PA require a message header structure
+   that contains a version, message class, message type, and message
+   length.  The header structure is shown in Figure 5.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Version    |     Spare     | Message Class | Message Type  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Message Length                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 5.  Common Message Header
+
+2.1.1.  Version
+
+   The version field contains the version of M2PA.  The supported
+   versions are:
+
+            Value
+          (decimal)  Version
+          ---------  -------
+              1      Release 1.0 of M2PA protocol
+
+2.1.2.  Spare
+
+   The Spare field SHOULD be set to all zeroes (0's) by the sender and
+   ignored by the receiver.  The Spare field SHOULD NOT be used for
+   proprietary information.
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 12]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+2.1.3.  Message Class
+
+   The following List contains the valid Message Classes:
+
+            Value
+          (decimal)  Message Class
+          ---------  -------------
+             11      M2PA Messages
+
+   Other values are invalid for M2PA.
+
+2.1.4.  Message Type
+
+   The following list contains the message types for the defined
+   messages.
+
+            Value
+          (decimal)  Message Type
+          ---------  -------------
+              1      User Data
+              2      Link Status
+
+   Other values are invalid.
+
+2.1.5.  Message Length
+
+   The Message Length defines the length of the message in octets,
+   including the Common Header.
+
+2.2.  M2PA Header
+
+   All protocol messages for M2PA require an M2PA-specific header.  The
+   header structure is shown in Figure 6.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     unused    |                      BSN                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     unused    |                      FSN                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 6.  M2PA-specific Message Header
+
+2.2.1.  Backward Sequence Number (BSN)
+
+   This is the FSN of the message last received from the peer.
+
+
+
+
+George, et al.              Standards Track                    [Page 13]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+2.2.2.  Forward Sequence Number (FSN)
+
+   This is the M2PA sequence number of the User Data message being sent.
+
+   The FSN and BSN values range from 0 to 16,777,215.
+
+2.3.  M2PA Messages
+
+   The following section defines the messages and parameter contents.
+   An M2PA message consists of a Common Message Header and M2PA Header,
+   followed by the data appropriate to the message.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                     Common Message Header                     /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                  M2PA-specific Message Header                 /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                         Message Data                          /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The field "Message Data" contains either:
+
+      - a User Data message (Section 2.3.1), or
+      - a Link State message (Section 2.3.2)
+
+2.3.1.  User Data
+
+   The User Data is the data sent from MTP3.  The User Data is an
+   optional field.  It need not be included in an acknowledgement-only
+   message.
+
+   The format of the User Data message is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   \                                                               \
+   /                            Data                               /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 14]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   The Data field contains the following fields of the MTP Message
+   Signal Unit (MSU):
+
+      - the Message Priority field (PRI)
+      - Service Information Octet (SIO)
+      - Signaling Information Field (SIF)
+
+   The MTP MSU is described in Q.703 [Q.703], Section 2.2, "Signal Unit
+   Format", and T1.111.3 [T1.111], Section 2.2, "Signal Unit Format".
+   The Japanese TTC standard uses the PRI field as an MTP3 Message
+   Priority field [JT-Q703] [JT-Q704].  For versions of MTP that do not
+   use these two bits, the entire first octet of the Data field is
+   spare.
+
+   The format of the first octet of the Data field is:
+
+       0
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |PRI|   spare   | (followed by SIO, SIF)
+      +-+-+-+-+-+-+-+-+
+
+      PRI - Priority used only in national MTP defined in [JT-Q703] and
+            [JT-Q704].  These bits are spare for other MTP versions.
+
+   Note that the Data field SHALL NOT contain other components of the
+   MTP MSU format:
+
+      - Flag
+      - Backward Sequence Number (BSN)
+      - Backward Indicator Bit (BIB)
+      - Forward Sequence Number (FSN)
+      - Forward Indicator Bit (FIB)
+      - Length Indicator (LI)
+      - Check bits (CK)
+
+   The Data field SHALL be transmitted in the byte order as defined by
+   MTP3.
+
+   M2PA SHALL NOT add padding to the MTP3 message.
+
+   Note: In the SS7 Recommendations, the format of the messages and
+   fields within the messages are based on bit transmission order.  In
+   these recommendations, the Least Significant Bit (LSB) of each field
+   is positioned to the right.  The received SS7 fields are populated
+   octet by octet as received into the 4-octet word, as shown below.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 15]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   As an example, in the ANSI MTP protocol, the Data field format is
+   shown below:
+
+      |MSB---------------------------------------------------------LSB|
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |PRI|   spare   |      SIO      |   SIF octet   |      ...      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                               :                               /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      ...      |      ...      |      ...      |   SIF octet   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Within each octet, the Least Significant Bit (LSB) per the SS7
+   Recommendations is to the right (e.g., bit 15 of SIO is the LSB).
+
+2.3.2.  Link Status
+
+   The MTP2 Link Status message can be sent between M2PA peers to
+   indicate link status.  This message performs a function similar to
+   the Link Status Signal Unit in MTP2.  The format of the Link Status
+   message is as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            State                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The valid values for State are shown in the following table.
+
+            Value
+          (decimal)  Description
+          ---------  -----------
+              1      Alignment
+              2      Proving Normal
+              3      Proving Emergency
+              4      Ready
+              5      Processor Outage
+              6      Processor Recovered
+              7      Busy
+              8      Busy Ended
+              9      Out of Service (OOS)
+
+
+
+
+
+George, et al.              Standards Track                    [Page 16]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+2.3.2.1.  Link Status Proving
+
+   The Link Status Proving message may optionally carry additional
+   bytes.  If the optional bytes are used, the format of the message is
+   as follows.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            State                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      \                                                               \
+      /                            filler                             /
+      \                                                               \
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   It is RECOMMENDED that the length of the Link Status Proving message
+   be similar to the size of the User Data messages that will be carried
+   on the link.
+
+   It is RECOMMENDED that the filler field contain a number pattern that
+   varies among the Link Status Proving messages, and that allows the
+   SCTP checksum [RFC3309] to be used to verify the accuracy of
+   transmission.
+
+3.  State Control
+
+3.1.  SCTP Association State Control
+
+   Figure 7 illustrates state changes in the M2PA management of the SCTP
+   association, together with the causing events.  Note that some of the
+   error conditions are not shown in the state diagram.
+
+   Following is a list of the M2PA Association States and a description
+   of each.
+
+   IDLE - State of the association during power-up initialization.
+
+   ASSOCIATING - M2PA is attempting to establish an SCTP association.
+
+   ESTABLISHED - SCTP association is established.
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 17]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+                         +-----------+
+                         |   IDLE    |
+                         +-----------+
+                               |
+                               | Associate
+                               | (Issue SCTP associate)
+                               |
+                               |   +----------------------+
+                               |   |         (Issue SCTP  |
+                               V   V          associate)  |
+                         +-------------+                  |
+                         | ASSOCIATING |----------------->+
+                         +-------------+  SCTP Comm Error |
+                               |                          |
+                               |                          |
+                               | SCTP Comm Up             |
+                               |                          |
+                               V                          |
+                         +-------------+                  |
+                         | ESTABLISHED |----------------->+
+                         +-------------+   SCTP Comm Error
+                                        OR SCTP Comm Lost
+
+           Figure 7.  M2PA Association State Transition Diagram
+
+3.2.  M2PA Link State Control
+
+   The M2PA link moves from one state to another in response to various
+   events.  The events that may result in a change of state include:
+
+      - MTP3 primitive requests
+
+      - Receipt of messages from the peer M2PA
+
+      - Expiration of timers
+
+      - SCTP notifications
+
+   These events affect the M2PA link state in a manner similar to MTP2.
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 18]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+4.  Procedures
+
+   Because M2PA provides MTP3 with an interface and functionality like
+   MTP2, its internal functioning is similar to that of MTP2.
+
+   Except as modified in this document, M2PA SHOULD follow the
+   requirements of the applicable MTP2 specification.  These may include
+   [Q.703] or [T1.111].  The same standard MUST be followed on both ends
+   of the M2PA link.
+
+   In particular, the corresponding applicable timer value defaults and
+   ranges specified for the applicable MTP2 standard should be used for
+   the M2PA timers.
+
+   When referring to MTP2 terminology in this document, the terminology
+   of [Q.703] is used.  This does not imply that the requirements of
+   [Q.703] are to be followed.
+
+4.1.  Procedures to Support MTP2 Features
+
+4.1.1.  Signal Unit Format, Delimitation, Acceptance
+
+   Messages for transmission across the network must follow the format
+   described in Section 2.
+
+   SCTP provides reliable, in-sequence delivery of user messages.
+   Therefore the related functionality of MTP2 is not needed.  SCTP does
+   not provide functions related to Link State Control in MTP2.  These
+   functions must be provided by M2PA.
+
+   Since SCTP provides delivery of messages, there is no need for M2PA
+   to delimit its messages with a flag, as is done in MTP2.
+   Furthermore, M2PA does not need to perform zero bit insertion and
+   deletion on its messages.
+
+   Since SCTP uses a checksum to detect transmission errors, there is no
+   need for an M2PA checksum, as is needed in MTP2.  This also
+   eliminates the need for the error rate monitors of MTP2.
+
+   Since SCTP provides reliable delivery and ordered delivery, M2PA does
+   not perform retransmissions.  This eliminates the need for the
+   forward and backward indicator bits in MTP2 signal units.
+
+   Acceptance of a message is indicated by a successful receipt of the
+   message from SCTP.
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 19]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+4.1.2.  MTP and SCTP Entities
+
+   This section describes how M2PA relates MTP and SCTP entities.
+
+   Each MTP link corresponds to an SCTP association.  To prevent
+   duplicate associations from being established, it is RECOMMENDED that
+   each endpoint know the IP address (or IP addresses, if multi-homing
+   is used) and port number of both endpoints.  SCTP prevents two
+   associations with the same IP addresses and port numbers from being
+   established.
+
+   It is necessary for at least one of the endpoints to be listening on
+   the port on which the other endpoint is trying to establish the
+   association.  Therefore, at least one of the port numbers SHOULD be
+   the M2PA registered port.
+
+   If only one association is to be established between these two IP
+   addresses, then the association SHOULD be established using the M2PA
+   registered port at each endpoint.
+
+   If it is desirable to create multiple associations (for multiple
+   links) between the two IP addresses, different port numbers can be
+   used for each association.  Nevertheless, the M2PA registered port
+   number SHOULD be used at one end of each association.
+
+   Each combination of IP address/port for the two endpoints (i.e., each
+   association) MUST be mapped to the same Signaling Link Code (SLC) at
+   each endpoint, so that each endpoint knows which link is being
+   created at the time the SCTP association is established.  However,
+   M2PA does not do any processing based on the SLC.
+
+   Following are examples of the relationships between associations and
+   links.  Note that a link is an SCTP association identified by two
+   endpoints.  Each endpoint is identified by an IP address and port
+   number.  Each association is mapped to an SLC.
+
+   Figure 8 shows a case with two IPSPs, each with two IP addresses.
+   Two associations are the links that connect the two IPSPs.  Since
+   these links are in the same link set, they MUST have different SLCs.
+
+   Table 1 shows the relationships in tabular form.  Table 1 is only
+   conceptual.  The actual method for mapping the SCTP associations to
+   the SLCs is implementation dependent.
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 20]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+                   IPSP X                        IPSP Y
+
+               +-------------+               +-------------+
+               |             |     SCTP      |             |
+               |         IPA | association 1 | IPB         |
+               |   port = PW +---------------+ port = PW   |
+               |     SLC = a |               | SLC = a     |
+               |             |               |             |
+               |             |               |             |
+               |             |     SCTP      |             |
+               |         IPC | association 2 | IPD         |
+               |   port = PW +---------------+ port = PW   |
+               |     SLC = b |               | SLC = b     |
+               |             |               |             |
+               |             |               |             |
+               +-------------+               +-------------+
+
+            IPx = IP address
+            PW  = Registered port number for M2PA
+
+               Figure 8.  Two IPSPs with Two IP Addresses Each
+
+
+        +-------------+---------------------------------------+-----+
+        | Association |      IPSP X       |      IPSP Y       | SLC |
+        |             +------------+------+------------+------+     |
+        |             | IP address | Port | IP address | Port |     |
+        +=============+============+======+============+======+=====+
+        |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
+        +-------------+------------+------+------------+------+-----+
+        |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
+        +-------------+------------+------+------------+------+-----+
+
+              Table 1.  Two IPSPs with Two IP Addresses Each
+
+   Figure 9 and Table 2 show an example with three IPSPs.  Note that in
+   this example, the two links are in different link sets.  Therefore,
+   it is possible that the SLC values a and b MAY be equal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 21]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+                   IPSP X                        IPSP Y
+
+               +-------------+               +-------------+
+               |             |     SCTP      |             |
+               |         IPA | association 1 | IPB         |
+               |   port = PW +---------------+ port = PW   |
+               |     SLC = a |               | SLC = a     |
+               |             |               |             |
+               |             |               |             |
+               |             |     SCTP      |             |
+               |         IPC | association 2 |             |
+               |   port = PW +-------+       |             |
+               |     SLC = b |       |       |             |
+               |             |       |       |             |
+               |             |       |       |             |
+               +-------------+       |       +-------------+
+                                     |
+                                     |
+                                     |           IPSP Z
+                                     |
+                                     |       +-------------+
+                                     |       |             |
+                                     |       | IPD         |
+                                     +-------+ port = PW   |
+                                             | SLC = b     |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             |             |
+                                             +-------------+
+
+            IPx = IP address
+            PW  = Registered port number for M2PA
+
+                 Figure 9.  One IPSP Connected to Two IPSPs
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 22]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+        +-------------+---------------------------------------+-----+
+        | Association |      IPSP X       |     IPSP Y/Z      | SLC |
+        |             +------------+------+------------+------+     |
+        |             | IP address | Port | IP address | Port |     |
+        +=============+============+======+============+======+=====+
+        |      1      |    IPA     |  PW  |    IPB     |  PW  |  a  |
+        +-------------+------------+------+------------+------+-----+
+        |      2      |    IPC     |  PW  |    IPD     |  PW  |  b  |
+        +-------------+------------+------+------------+------+-----+
+
+                 Table 2.  One IPSP Connected to Two IPSPs
+
+   Figure 10 and Table 3 show two associations between the same IP
+   addresses.  This is accomplished by using different port numbers for
+   each association at one endpoint.
+
+                   IPSP X                        IPSP Y
+
+               +-------------+               +-------------+
+               |             |     SCTP      |             |
+               |         IPA | association 1 | IPB         |
+               |   port = P1 +---------------+ port = PW   |
+               |     SLC = a |               | SLC = a     |
+               |             |               |             |
+               |             |               |             |
+               |             |     SCTP      |             |
+               |         IPA | association 2 | IPB         |
+               |   port = PW +---------------+ port = PW   |
+               |     SLC = b |               | SLC = b     |
+               |             |               |             |
+               |             |               |             |
+               +-------------+               +-------------+
+
+            IPx = IP address
+            P1  = Pre-selected port number
+            PW  = Registered port number for M2PA
+
+             Figure 10.  Multiple Associations Between Two IP Addresses
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 23]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+        +-------------+---------------------------------------+-----+
+        | Association |      IPSP X       |      IPSP Y       | SLC |
+        |             +------------+------+------------+------+     |
+        |             | IP address | Port | IP address | Port |     |
+        +=============+============+======+============+======+=====+
+        |      1      |    IPA     |  P1  |    IPB     |  PW  |  a  |
+        +-------------+------------+------+------------+------+-----+
+        |      2      |    IPA     |  PW  |    IPB     |  PW  |  b  |
+        +-------------+------------+------+------------+------+-----+
+
+           Table 3.  Multiple Associations Between Two IP Addresses
+
+   The association SHALL contain two streams in each direction.  Stream
+   0 is designated for Link Status messages.  Stream 1 is designated for
+   User Data messages, as well as Link Status messages that must remain
+   in sequence with the User Data messages.
+
+   The following Link Status messages SHALL be sent on the Link Status
+   stream (stream 0):
+
+      - Alignment
+      - Proving Normal
+      - Proving Emergency
+      - Ready (when sent during alignment)
+      - Busy
+      - Busy Ended
+      - Out of Service
+
+   The following Link Status messages SHALL be sent on the User Data
+   stream (stream 1):
+
+      - Processor Outage
+      - Processor Recovered
+      - Ready (when sent at the end of processor outage)
+
+4.1.3.  Link Alignment
+
+   The purposes of the alignment procedure are:
+
+      (1) To provide a handshaking procedure so that both endpoints are
+          prepared to send SS7 traffic, and to prevent traffic from
+          being sent before the other end is ready.
+
+      (2) To verify that the SCTP association is suitable for use as an
+          SS7 link.
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 24]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   Link alignment takes place after the association is established.  If
+   SCTP fails to establish the association, and M2PA has received a
+   Start Request from its MTP3, then M2PA SHALL report to MTP3 that the
+   link is out of service.
+
+   The Link Status Out of Service message replaces the SIOS message of
+   MTP2.  Unlike MTP2, the message SHOULD NOT be transmitted
+   continuously.  After the association is established, M2PA SHALL send
+   a Link Status Out of Service message to its peer.  Prior to the
+   beginning of alignment, M2PA MAY send additional Link Status Out of
+   Service messages.
+
+   The Link Status Alignment message replaces the SIO message of MTP2.
+   This message is sent to signal the beginning of the alignment
+   procedure.  The Link Status Alignment message SHOULD NOT be
+   transmitted continuously.  M2PA MAY send additional Link Status
+   Alignment until it receives Link Status Alignment, Link Status
+   Proving Normal, or Link Status Proving Emergency from the peer.
+
+   The Link Status Proving Normal message replaces the SIN message of
+   MTP2.  The Link Status Proving Emergency message replaces the SIE
+   message of MTP2.
+
+   The proving period MAY be omitted if this is allowed by the
+   applicable MTP2 standard (e.g., [Q.2140]).
+
+   If proving is performed, then during the proving period (i.e., after
+   M2PA starts the proving period timer T4), M2PA SHALL send Link Status
+   Proving messages to its peer at an interval defined by the protocol
+   parameter Proving_Interval.  It is RECOMMENDED that Proving_Interval
+   be set so that the traffic load generated with the Link Status
+   Proving messages during the proving period is comparable to the
+   normal traffic load expected when the link is in service.
+
+   The Link Status Ready message replaces the FISU of MTP2 that is sent
+   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.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 25]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+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 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
+
+
+
+George, et al.              Standards Track                    [Page 26]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   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]).
+
+   In other respects, M2PA SHOULD follow the same procedures as MTP2 in
+   processor outage.
+
+4.1.5.  Level 2 Flow Control
+
+   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.
+
+
+
+George, et al.              Standards Track                    [Page 27]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   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.
+
+4.1.6.  Link Out of Service
+
+   The Link Status Out of Service message replaces the SIOS message of
+   MTP2.  Unlike MTP2, the message SHOULD NOT be transmitted
+   continuously.  M2PA SHALL send a Link Status Out of Service message
+   to its peer at the beginning of a condition where MTP2 would send
+   SIOS.  M2PA MAY send additional Link Status Out of Service messages
+   as long as that condition persists.
+
+   When M2PA places a link in the OUT OF SERVICE state, M2PA SHOULD NOT
+   terminate the SCTP association.
+
+4.1.7.  SCTP Association Problems
+
+   The SCTP association for a link may become unusable, such as when one
+   of the following occurs:
+
+      - SCTP sends a Send Failure notification to M2PA.
+
+      - SCTP sends a Communication Lost notification to M2PA.
+
+      - SCTP sends a Communication Error notification to M2PA.
+
+      - The SCTP association is lost.
+
+   If the SCTP association for a link becomes unable to transmit or
+   receive messages, M2PA SHALL report to MTP3 that the link is out of
+   service and enter the OUT OF SERVICE state.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 28]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+4.1.8.  Transmission and Reception Priorities
+
+   In MTP, Link Status messages have priority over User Data messages
+   ([Q.703], Section 11.2).  To achieve this in M2PA, M2PA uses separate
+   streams in its SCTP association for Link Status messages and User
+   Data messages.
+
+   M2PA SHALL send all messages using the ordered delivery option of
+   SCTP.
+
+   M2PA SHOULD give higher priority to messages sent on the Link Status
+   stream than to messages sent on the User Data stream when sending
+   messages to SCTP.
+
+   M2PA SHOULD give higher priority to reading the Link Status stream
+   than to reading the User Data stream.
+
+   M2PA SHOULD give higher priority to receiving notifications from SCTP
+   than to reading either the Link Status stream or the User Data
+   stream.
+
+4.1.9.  M2PA Version Control
+
+   A node upgraded to a newer version of M2PA SHOULD support the older
+   versions used on other nodes with which it is communicating.  If that
+   is the case, then alignment can proceed normally.
+
+   In particular, it is recommended that for future modifications to
+   this protocol:
+
+      - Any newer version SHOULD be able to process the messages from an
+        older version.
+
+      - A newer version of M2PA SHOULD refrain from sending messages to
+        an older version of M2PA messages that the older version cannot
+        process.
+
+      - If an older version of M2PA receives a message that it cannot
+        process, it SHOULD discard the message.
+
+      - In cases where different processing is done in two versions for
+        the same format of a message, then the newer version SHOULD
+        contain procedures to recognize and handle this appropriately.
+
+   In case a newer version of M2PA is incompatible with an older
+   version, the newer version SHOULD recognize this and prevent the
+   alignment of the link.  If a Link Status Alignment message with an
+
+
+
+
+George, et al.              Standards Track                    [Page 29]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   unsupported version is received by the newer version, the receiving
+   end's M2PA SHOULD reply with a Link Status Out of Service message and
+   not complete the alignment procedure.
+
+4.2.  Procedures to Support the MTP3/MTP2 Interface
+
+4.2.1.  Sending and Receiving Messages
+
+   When MTP3 sends a message for transmission to M2PA, M2PA passes the
+   corresponding M2PA message to SCTP using the SEND primitive.
+
+   User Data messages SHALL be sent via the User Data stream (stream 1)
+   of the association.
+
+   M2PA Link Status messages are passed to SCTP using the SEND
+   primitive.
+
+   The following Link Status messages SHALL be sent on the Link Status
+   stream (stream 0):
+
+      - Alignment
+      - Proving Normal
+      - Proving Emergency
+      - Ready (when sent during alignment)
+      - Busy
+      - Busy Ended
+      - Out of Service
+
+   The following Link Status messages SHALL be sent on the User Data
+   stream (stream 1):
+
+      - Processor Outage
+      - Processor Recovered
+      - Ready (when sent at the end of processor outage)
+
+   If M2PA receives a message from SCTP with an invalid Message Class or
+   unsupported Message Type in the Common Message Header, M2PA SHALL
+   discard the message.
+
+   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
+   order, M2PA SHALL discard the message.
+
+   Note: In all calculations involving FSN and BSN, the programmer
+   should be aware that the value wraps around to 0 after reaching its
+   maximum value.
+
+
+
+George, et al.              Standards Track                    [Page 30]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   When there is a message to acknowledge, M2PA MUST acknowledge the
+   message with the next User Data message sent.  If there is no User
+   Data message available to be sent when there is a message to
+   acknowledge, M2PA SHOULD generate and send a User Data message with
+   no data payload, without delay.  (In other words, in the case where
+   MTP2 would acknowledge a message with a FISU, M2PA SHOULD acknowledge
+   the message with an empty User Data message.)  The FSN for this empty
+   User Data message is not incremented.  It MUST contain the same FSN
+   as the most recently sent User Data message that contains data.
+   Delaying of acknowledgements can result in poor SS7 performance.
+
+   If M2PA receives an empty User Data message, it SHALL NOT send an
+   acknowledgement of that message.
+
+   Note that there is no reason to place Link Status messages or empty
+   User Data messages in the M2PA retransmit buffer, since these
+   messages are not retrieved for changeover and timer T7 does not apply
+   to them.
+
+   Note that since SCTP provides reliable delivery and ordered delivery
+   within the stream, M2PA does not perform retransmissions.
+   Nevertheless, M2PA SHALL retain transmitted User Data messages in a
+   retransmit queue until they are acknowledged.  These messages are
+   needed in case MTP3 performs data retrieval as part of a changeover
+   procedure.
+
+   Because propagation delays in IP networks are more variable than in
+   traditional SS7 networks, a single T7 timer (excessive delay of
+   acknowledgement), as in MTP2, is inadequate.  If any message is
+   unacknowledged after a period equal to the T7 value, the T7 timer
+   SHALL expire.
+
+4.2.2.  MTP3 Signaling Link Congestion
+
+   M2PA SHALL detect transmit congestion in its buffers according to the
+   requirements for signaling link transmit congestion in MTP3, e.g.,
+   Q.704 [Q.704], Section 3.8.
+
+4.2.3.  Changeover
+
+   The objective of the changeover is to ensure that signaling traffic
+   carried by the unavailable signaling link is diverted to the
+   alternative signaling link(s) as quickly as possible while avoiding
+   message loss, duplication, or mis-sequencing.  For this purpose, the
+   changeover procedure includes data retrieval, which is performed
+   before opening the alternative signaling links to the diverted
+   traffic.  Data retrieval consists of these steps:
+
+
+
+
+George, et al.              Standards Track                    [Page 31]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+      (1) buffer updating, i.e., identifying all those User Data
+          messages in the retransmission buffer of the unavailable
+          signaling link which have not been received by the far end
+          M2PA, as well as untransmitted messages, and
+
+      (2) transferring those messages to the transmission buffers of the
+          alternate links.
+
+   Note that only User Data messages containing data are retrieved and
+   transmitted over the alternate links.  Link Status messages and empty
+   User Data messages SHALL NOT be retrieved and transmitted over the
+   alternate links.
+
+   M2PA's Sequence Numbers are 24 bits long.  MTP2's Forward and
+   Backward Sequence Numbers are only seven bits long.  Hence, it is
+   necessary for MTP3 to accommodate the larger sequence numbers.  This
+   is done through the use of the Extended Changeover Order (XCO) and
+   Extended Changeover Acknowledgement (XCA) messages instead of the
+   Changeover Order (COO) and Changeover Acknowledgement (COA) messages.
+   The XCO and XCA messages are specified in [Q.2210] Section 9.8.1 and
+   T1.111.4 [T1.111], Section 15.4.  Only the XCO and XCA messages from
+   [Q.2210] or [T1.111] are required.  The BSN is placed in the XCO/XCA
+   message as explained in [Q.2210] and [T1.111].
+
+   Also, the following MTP3/MTP2 primitives MUST use the larger sequence
+   numbers:
+
+      - BSNT Confirmation
+
+      - Retrieval Request and FSNC
+
+   If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA
+   SHALL retrieve from its buffers and deliver to MTP3 in order:
+
+      (a) any transmitted User Data messages beginning with the first
+          unacknowledged message with FSN greater than FSNC.
+
+      (b) any untransmitted User Data messages.
+
+   For emergency changeover, MTP3 retrieves only the unsent messages for
+   transmission on the alternate link(s).  If M2PA receives a Retrieval
+   Request and FSNC request with no FSNC value, or with an invalid FSNC,
+   then M2PA SHALL retrieve from its buffers and deliver to MTP3 in
+   order:
+
+      (a) any untransmitted User Data messages.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 32]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   The Japanese TTC version of MTP defined in [JT-Q703] and [JT-Q704]
+   has a Retrieval Request (as well as Retrieval Request and FSNC).  The
+   Retrieval allows MTP3 to retrieve both unsent and unacknowledged
+   messages for transmission on the alternate link(s).  In this version
+   of MTP, if M2PA receives a Retrieval Request, then M2PA SHALL
+   retrieve from its buffers and deliver to MTP3 in order:
+
+      (a) any transmitted but unacknowledged User Data messages.
+
+      (b) any untransmitted User Data messages.
+
+4.2.3.1.  Multiple User Data Streams and Changeover
+
+   The changeover procedure makes it problematic for M2PA to have
+   multiple User Data streams in one direction for a link.  Buffer
+   updating would have to be done separately for each User Data stream
+   to avoid duplication or loss of messages.  But MTP3 provides for only
+   one XCO/XCA message for sending the last-received sequence number.
+
+   Even with sequence numbering of User Data messages at the M2PA layer,
+   it is necessary to perform buffer updating on each stream.  Since the
+   M2PA messages would be delivered over multiple streams, there could
+   be a gap in the M2PA sequence numbers at the receiving end when the
+   changeover procedure begins.  If only the M2PA sequence number is
+   used in the XCO/XCA message, there would be a possibility of losing
+   the messages in the gap, or duplicating messages after the gap.
+
+   M2PA links with multiple User Data streams would be possible if a
+   multiple-BSNT XCO/XCA message is defined in MTP3, or if MTP3 allows
+   multiple XCO/XCA messages (one for each User Data stream) to be sent
+   during a changeover.  This is beyond the scope of this document.
+
+4.3.  SCTP Considerations
+
+   Some M2PA procedures may be affected by the use of SCTP as a
+   transport layer.  These considerations are discussed in this section.
+
+4.3.1.  SCTP Slow Start
+
+   SCTP contains a slow start algorithm to control the amount of data
+   being injected into the network.  The algorithm allows SCTP to probe
+   the network to determine the available capacity.  The algorithm is
+   invoked in these cases: when transmission begins on an association,
+   after a sufficiently long idle period, or after repairing loss
+   detected by the SCTP retransmission timer.
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 33]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   It is possible that transmission of M2PA messages MAY be delayed by
+   SCTP slow start under certain conditions, including the following:
+
+      (a) Link Alignment.  Link alignment takes place after an
+          association is established.  SCTP invokes the slow start
+          algorithm since transmission is beginning on the association.
+
+      (b) Changeover.  Messages are retrieved from one link
+          (association) and transferred to another for transmission.  If
+          the second link had previously been idle, or is in the process
+          of link alignment, SCTP may invoke the slow start algorithm.
+
+      (c) Path failure (multi-homing).  If SCTP switches from a failed
+          path to a new path, and the new path had previously been idle,
+          SCTP may invoke the slow start algorithm.
+
+      (d) Reduced traffic volume.  Any time that M2PA sends a low volume
+          of traffic on a link and then the volume increases, SCTP may
+          invoke the slow start algorithm.
+
+   Programmers should be aware of this condition and how it may affect
+   M2PA performance.  In some cases, it may be possible to avoid the
+   negative effects of slow start.  For example, the Link Status Proving
+   messages sent during the proving period may be used to complete slow
+   start before the link is placed in service.
+
+5.  Examples of M2PA Procedures
+
+   In general, messages passed between MTP3 and M2PA are the same as
+   those passed between MTP3 and MTP2.  M2PA interprets messages from
+   MTP3 and sends the appropriate message to SCTP.  Likewise, messages
+   from SCTP are used to generate a meaningful message to MTP3.
+
+   Note that throughout this section, the primitives between MTP3 and
+   M2PA are named using the MTP terminology [Q.700] [Q.701] [Q.702]
+   [Q.703] [Q.704] [Q.705].  Communications between M2PA and SCTP are
+   named using SCTP terminology.
+
+5.1.  Link Initialization (Alignment)
+
+   An example of the message flow used to bring an SS7 link in service
+   is shown in Figures 11 and 12.  Alignment is done by both ends of the
+   link.  To simplify the diagram, alignment is shown on one end only.
+   Some messages from the remote end are not shown.  It is assumed in
+   this example that SCTP has been initialized.
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 34]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Associate   .           .           .           .
+        .           ------------>           .           .           .
+        .           .           .           .           .           .
+        .           .           (SCTP Association       .           .
+        .           .            procedure)             .           .
+        .           .           .           .           .           .
+        .           Communication Up        Communication Up        .
+        .           <------------           ------------>           .
+        .           .           .           .           .           .
+        .           Link Status Out of Service          .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        Emergency OR            .           .           .           .
+        Emergency Ceases        .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        Start       .           .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        .           .           .           .           .           .
+        .           Link Status Alignment   .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           Start timer T2          .           .           .
+        .           .           .           .           .           .
+        .           .           .   Link Status Alignment           .
+        .           <------------------------------------           .
+        .           .           .           .           .           .
+        .           Stop timer T2           .           .           .
+        .           .           .           .           .           .
+
+        Proving period begins.
+
+           Figure 11.  Example: Link Initialization - Alignment
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 35]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Start timer T3          .           .           .
+        .           Link Status Proving     .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .     Link Status Proving           .
+        .           <------------------------------------           .
+        .           .           .           .           .           .
+        .           Stop timer T3           .           .           .
+        .           .           .           .           .           .
+        .           Start timer T4          .           .           .
+        .           Link Status Proving     .           .           .
+        .           ------------------------------------>           .
+        .           ------------------------------------>           .
+        .           ------------------------------------>           .
+        .           ------------------------------------>           .
+        .           ------------------------------------>           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           Timer T4 expires        .           .           .
+        .           .           .           .           .           .
+
+        Send Link Status Ready (one or more) and wait for the remote end
+        to complete its proving period.
+
+        .           .           .           .           .           .
+        .           Start timer T1          .           .           .
+        .           .           .           .           .           .
+        .           Link Status Ready       .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .           .           .
+        .           .           .       Link Status Ready           .
+        .           <------------------------------------           .
+        .           .           .           .           .           .
+        .           Stop timer T1           .           .           .
+        .           .           .           .           .           .
+        In Service              .           .           In Service
+        <------------           .           .           ------------>
+        .           .           .           .           .           .
+
+        MTP3 MAY begin sending data messages.
+
+            Figure 12.  Example: Link Initialization - Proving
+
+
+
+
+
+George, et al.              Standards Track                    [Page 36]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+5.2.  Message Transmission and Reception
+
+   Messages are transmitted using the Data Request primitive from MTP3
+   to M2PA.  Figure 13 shows the case where the Link is In Service.  The
+   message is passed from MTP3 of the source to MTP3 of the destination.
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        Message for             .           .           .           .
+        transmission            .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        .           Send        .           .           .           .
+        .           (Data Message)          .           .           .
+        .           ------------>           .           .           .
+        .           .           .           .           .           .
+        .           .           (SCTP sends message)    .           .
+        .           .           .           .           .           .
+        .           .           .           Receive                 .
+        .           .           .           ------------>           .
+        .           .           .           .           .           .
+        .           .           .           .        Received message
+        .           .           .           .           ------------>
+        .           .           .           .           .           .
+
+            Figure 13.  Example: Link Initialization - In Service
+
+5.3.  Link Status Indication
+
+   An example of a Link Status Indication is shown in Figure 14.  If
+   SCTP sends a Communication Lost primitive to M2PA, M2PA notifies MTP3
+   that the link is out of service.  MTP3 responds in its usual way.
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Communication Lost      .           .           .
+        .           <------------           .           .           .
+        .           .           .           .           .           .
+        Out of Service          .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+
+                Figure 14.  Example: Link Status Indication
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 37]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+5.4.  Link Status Message (Processor Outage)
+
+   Figure 15 shows how M2PA responds to a local processor outage.  M2PA
+   sends a Link Status message to its peer.  The peer M2PA notifies MTP3
+   of the outage.  MTP3 can then follow the processor outage procedures
+   as in [Q.703].
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .       M2PA detects    .           .           .           .
+        .       Local Processor .           .           .           .
+        .       Outage          .           .           .           .
+        .           .           .           .           .           .
+        .           Link Status .           .           .           .
+        .           Processor Outage        .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .        Remote Processor
+        .           .           .           .        Outage         .
+        .           .           .           .           ------------>
+        .           .           .           .           .           .
+        .           Link Status             .           .           .
+        .           Processor               .           .           .
+        .           Recovered               .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .        Remote Processor
+        .           .           .           .        Outage Ceases
+        .           .           .           .           ------------>
+        .           .           .           .           .           .
+        .           .           .       Link Status Ready           .
+        .           <------------------------------------           .
+        .           .           .           .           .           .
+        .           Link Status Ready       .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        Message for             .           .           .           .
+        transmission            .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        .           User Data               .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+
+        Figure 15.  Example: Link Status Message - Processor Outage
+
+
+
+
+
+George, et al.              Standards Track                    [Page 38]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   Figure 16 shows an example of processor outage in more detail.  All
+   M2PA messages in this example are sent on the Data stream (stream 1).
+
+                    A                                   B
+       ----------------------------        ----------------------------
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        6 Messages for          .           .           .           .
+        transmission            .           .           .           .
+        ------------>           .           .          6 Messages for
+        .           .           .           .            transmission
+        .           .           .           .           <------------
+        .           User Data FSN=1         .           .           .
+        .           ------------------------------------>           .
+        .           User Data FSN=2         .           .           .
+        .           ------------------------------------>           .
+        .           User Data FSN=3         .           .           .
+        .           ------------------------------------>           .
+        .           .           .        User Data FSN=11           .
+        .           <------------------------------------           .
+        .           .           .        User Data FSN=12           .
+        .           <------------------------------------           .
+        .           .           .        User Data FSN=13           .
+        .           <------------------------------------           .
+
+   Side A detects LPO.
+
+        .           .           .           .           .           .
+        .           .           .  User Data FSN=14 BSN=3           .
+        .           <------------------------------------           .
+        .           .           .  User Data FSN=15 BSN=3           .
+        .           <------------------------------------           .
+        .           .           .  User Data FSN=16 BSN=3           .
+        .           <------------------------------------           .
+        .           LS PO FSN=3 BSN=11      .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .        Remote Processor
+        .           .           .           .        Outage         .
+        .           .           .           .           ------------>
+
+   While in LPO, A must buffer messages 14-16 without acknowledging
+   them.  A may continue transmitting messages from MTP3, and
+   acknowledging messages that were received before LPO.
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 39]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+        .           .           .           .           .           .
+        .           User Data FSN=4 BSN=13  .           .           .
+        .           ------------------------------------>           .
+        .           User Data FSN=5 BSN=13  .           .           .
+        .           ------------------------------------>           .
+        .           User Data FSN=6 BSN=13  .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+
+    While in RPO, B may continue acknowledging messages.  Suppose that
+    B receives message 4 and 5, but has not processed 6 yet.
+
+         .           .           .           .           .           .
+         .                  (empty) User Data FSN=16 BSN=4
+         .           <------------------------------------           .
+         .                  (empty) User Data FSN=16 BSN=5
+         .           <------------------------------------           .
+
+    LPO ends at A.  A flushes 14-16 (the messages that were buffered
+    without acknowledgement).
+
+         .           .           .           .           .           .
+         .           LS PR FSN=6 BSN=13      .           .           .
+         .           ------------------------------------>           .
+         .           .           .           .        Remote Processor
+         .           .           .           .        Outage Ceases
+         .           .           .           .           ------------>
+         .           .           .           .           .           .
+
+    Suppose that B processed message 5, but never processed message 6.
+    B flushes message 6 from its Receive Buffer.  B notifies A of this
+    using the Link Status Ready message setting BSN=5, the last message
+    that was processed at B.
+
+         .           .           .           .           .           .
+         .           .           .           .           .           .
+         .           .           .   LS Ready FSN=13 BSN=5           .
+         .           <------------------------------------           .
+         .           .           .           .           .           .
+
+    B has completed synchronization of sequence numbers and has sent
+    an LS Ready, so it is able to resume sending data at this point
+    with the new sequence numbers (starting with FSN=14).
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 40]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+         .           .           .           .           .           .
+         .           .           .           .           . Message for
+         .           .           .           .            transmission
+         .           .           .           .           <------------
+         .           .           .  User Data FSN=14 BSN=5           .
+         .           <------------------------------------           .
+         .           .           .           .           .           .
+
+    A can use the Link Status Ready information to resynchronize its
+    sequence numbers to begin with FSN=6 in the next User Data message.
+
+         .           .           .           .           .           .
+         .           LS Ready FSN=5 BSN=13   .           .           .
+         .           ------------------------------------>           .
+         .           .           .           .           .           .
+
+    A has completed synchronization of sequence number and has both
+    received and sent an LS Ready, so it is able to resume sending data
+    at this point with the new sequence numbers and acknowledging data
+    received after receiving LS Ready.
+
+
+         .           .           .           .           .           .
+         .           .           .           .           .           .
+         .           User Data FSN=5 BSN=14 (empty)      .           .
+         .           ------------------------------------>           .
+         .           .           .           .           .           .
+         Message for             .           .           . Message for
+         transmission            .           .            transmission
+         ------------>           .           .           <------------
+         .           User Data FSN=6 BSN=14  .           .           .
+         .           ------------------------------------>           .
+         .           .           .  User Data FSN=15 BSN=5           .
+         .           <------------------------------------           .
+         .           .           .           .           .           .
+         .           .      (empty) User Data FSN=15 BSN=6           .
+         .           <------------------------------------           .
+         .           User Data FSN=6 BSN=15 (empty)      .           .
+         .           ------------------------------------>           .
+         .           .           .           .           .           .
+         .           .           .           .           .           .
+         .           .           .           .           .           .
+
+            Figure 16.  Example: Processor Outage and Recovery
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 41]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+5.5.  Level 2 Flow Control
+
+   Figures 17 and 18 illustrate the Level 2 Flow Control procedure.  In
+   Figure 17, congestion ceases before timer T6 expires.  Figure 18
+   shows the case where T6 expires.
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Implementation dependent            .           .
+        .           determination of M2PA               .           .
+        .           receive congestion onset            .           .
+        .           .           .           .           .           .
+        .           Link Status Busy        .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .          Start        .
+        .           .           .           .          Timer T6     .
+        .           .           .           .           .           .
+        .           Implementation dependent            .           .
+        .           determination of M2PA               .           .
+        .           receive congestion abatement        .           .
+        .           .           .           .           .           .
+        .           Link Status Busy Ended  .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .          Stop         .
+        .           .           .           .          Timer T6     .
+        .           .           .           .           .           .
+
+       Figure 17.  Example: Level 2 Flow Control - Congestion Ceases
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 42]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Implementation dependent            .           .
+        .           determination of M2PA               .           .
+        .           receive congestion onset            .           .
+        .           .           .           .           .           .
+        .           Link Status Busy        .           .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        .           .           .           .          Start        .
+        .           .           .           .          Timer T6     .
+        .           .           .           .            :          .
+        .           .           .           .            :          .
+        .           .           .           .          Timer T6     .
+        .           .           .           .          Expires      .
+        .           .           .           .           .           .
+        .           .          Link Status Out of Service           .
+        .           <------------------------------------           .
+        .           .           .           .           .           .
+        .           .           .           .          Out of Service
+        .           .           .           .           ------------>
+        .           .           .           .           .           .
+
+       Figure 18.  Example: Level 2 Flow Control - Timer T6 Expires
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 43]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+5.6.  MTP3 Signaling Link Congestion
+
+   In Figure 19, M2PA notifies MTP3 of congestion onset and abatement.
+   The notification includes the congestion level, if there are levels
+   of congestion defined.
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Implementation dependent            .           .
+        .           determination of M2PA   .           .           .
+        .           transmit congestion     .           .           .
+        .           onset (level)           .           .           .
+        .           .           .           .           .           .
+        Congestion Indication   .           .           .           .
+        (level)     .           .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+        .           Implementation dependent            .           .
+        .           determination of M2PA   .           .           .
+        .           transmit congestion     .           .           .
+        .           abatement (level)       .           .           .
+        .           .           .           .           .           .
+        Congestion Indication   .           .           .           .
+        (level)     .           .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+
+            Figure 19.  Example: MTP3 Signaling Link Congestion
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 44]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+5.7.  Link Deactivation
+
+   Figure 20 shows an example of link deactivation.  MTP3 can request
+   that a link be taken out of service.
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        Stop        .           .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        .           Link Status Out of Service          .           .
+        .           ------------------------------------>           .
+        .           .           .           .           .           .
+        Out of Service          .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+
+                  Figure 20.  Example: Link Deactivation
+
+5.8.  Link Changeover
+
+   In Figure 21, MTP3 performs a changeover because the link went out of
+   service.  MTP3 selects a different link to retransmit the
+   unacknowledged and unsent messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 45]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+       MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
+       ----        ----        ----        ----        ----        ----
+        .           .           .           .           .           .
+        .           Communication Lost      .           .           .
+        .           <------------           .           .           .
+        .           .           .           .           .           .
+        Out of Service          .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+        Retrieve BSNT           .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        BSNT Confirmation       .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+        XCO (BSNT) on another link          .           .           .
+        ------------------------------------------------------------>
+        .           .           .           .           .           .
+        .           .           .           .           Retrieve BSNT
+        .           .           .           .           <------------
+        .           .           .           .           .           .
+        .           .           .           .       BSNT Confirmation
+        .           .           .           .           ------------>
+        .           .           .           .           .           .
+        .           .           .           .           .  XCA (BSNT)
+        <------------------------------------------------------------
+        .           .           .           .           .           .
+        Retrieval Request       .           .           .           .
+        and FSNC    .           .           .           .           .
+        ------------>           .           .           .           .
+        .           .           .           .           .           .
+        Retrieved Message       .           .           .           .
+        <------------           .           .           .           .
+        .  :        .           .           .           .           .
+        .  :        .           .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+        Retrieval Complete      .           .           .           .
+        <------------           .           .           .           .
+        .           .           .           .           .           .
+        Send messages on another link.
+
+                   Figure 21.  Example: Link Changeover
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 46]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+6.  Security Considerations
+
+   M2PA is designed to carry signaling messages for telephony services.
+   As such, M2PA MUST involve the security needs of several parties:
+
+      - the end users of the services
+
+      - the network providers
+
+      - the applications involved
+
+   Additional requirements MAY come from local regulation.
+
+   While these parties may have some overlapping security needs, their
+   needs may not be identical.  Any security solution SHOULD fulfill all
+   of the different parties' needs.
+
+   Consult [RFC3788] for a discussion of security requirements and for
+   guidance on the use of security protocols.  Implementers of M2PA MUST
+   follow the guidelines in [RFC3788].
+
+7.  IANA Considerations
+
+7.1.  SCTP Payload Protocol Identifier
+
+   The SCTP Registered User Port Number Assignment for M2PA is 3565.
+   The TCP Registered User Port Number 3565 is also assigned to M2PA, in
+   case a specification for M2PA over TCP is created.
+
+   The value assigned by IANA for the Payload Protocol Identifier in the
+   SCTP Payload Data chunk is
+
+        M2PA     5
+
+   The SCTP Payload Protocol Identifier is included in each SCTP Data
+   chunk, to indicate which protocol the SCTP is carrying.  This Payload
+   Protocol Identifier is not directly used by SCTP but may be used by
+   certain network entities to identify the type of information being
+   carried in a Data chunk.
+
+   The User Adaptation peer may use the Payload Protocol Identifier as a
+   way of determining additional information about the data being
+   presented to it by SCTP.
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 47]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+7.2.  M2PA Protocol Extensions
+
+   This protocol may be extended through IANA in three ways:
+
+      - through definition of additional message classes,
+
+      - through definition of additional message types, and
+
+      - through definition of additional message parameters.
+
+   The definition and use of new message classes, types, and parameters
+   is an integral part of SIGTRAN adaptation layers.  Thus, these
+   extensions are assigned by IANA through an IETF Consensus action as
+   defined in [RFC2434].
+
+   The proposed extension must in no way adversely affect the general
+   working of the protocol.
+
+   The defined values for the message classes, types, and parameters are
+   listed in the Signaling User Adaptation Layer registry
+   (sigtran-adapt).
+
+7.2.1.  IETF Defined Message Classes
+
+   The documentation for a new message class MUST include the following
+   information:
+
+      (a) A long and short name for the message class.
+
+      (b) A detailed description of the purpose of the message class.
+
+7.2.2 IETF Defined Message Types
+
+   Documentation of the message type MUST contain the following
+   information:
+
+      (a) A long and short name for the new message type.
+
+      (b) A detailed description of the structure of the message.
+
+      (c) A detailed definition and description of the intended use of
+          each field within the message.
+
+      (d) A detailed procedural description of the use of the new
+          message type within the operation of the protocol.
+
+      (e) A detailed description of error conditions when receiving this
+          message type.
+
+
+
+George, et al.              Standards Track                    [Page 48]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   When an implementation receives a message type that it does not
+   support, it MUST discard the message.
+
+7.2.3.  IETF-defined Parameter Extension
+
+   Documentation of the message parameter MUST contain the following
+   information:
+
+      (a) Name of the parameter type.
+
+      (b) Detailed description of the structure of the parameter field.
+
+      (c) Detailed definition of each component of the parameter value.
+
+      (d) Detailed description of the intended use of this parameter
+          type, and an indication of whether, and under what
+          circumstances, multiple instances of this parameter type may
+          be found within the same message type.
+
+7.2.4.  Defined Values
+
+   This section lists the values defined in this document that should be
+   included in the Signaling User Adaptation Layer registry
+   (sigtran-adapt).
+
+   The following values for Message Class are defined in this document:
+
+            Value
+          (decimal)  Message Class
+          ---------  -------------
+             11      M2PA Messages
+
+   The following values for Message Type are defined in this document:
+
+            Value
+          (decimal)  Message Type
+          ---------  -------------
+              1      User Data
+              2      Link Status
+
+8.  Acknowledgements
+
+   The authors would like to thank the following for their valuable
+   comments and suggestions: Brian Tatum, Wayne Davis, Cliff Thomas,
+   Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina, Greg
+   Sidebottom, Al Varney, Jeff Craig, and Andrew Booth.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 49]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+9.  References
+
+9.1.  Normative References
+
+   [JT-Q703]  TTC, "Message Transfer Part Signalling Link," TTC Standard
+              JT-Q703, Telecommunication Technology Committee (TTC),
+              version 3 (April 27, 1994).
+
+   [JT-Q704]  TTC, "Message Transfer Part Signalling Network Functions,"
+              TTC Standard JT-Q704, Telecommunication Technology
+              Committee (TTC), version 4 (May 30, 2002).
+
+   [Q.703]    ITU, "Signalling System No. 7 - Signalling Link," ITU-T
+              Recommendation Q.703, ITU-T Telecommunication
+              Standardization Sector of ITU (July 1996).
+
+   [Q.704]    ITU, "Message Transfer Part - Signalling Network Functions
+              and Messages," ITU-T Recommendation Q.704, ITU-T
+              Telecommunication Standardization Sector of ITU (July
+              1996).
+
+   [Q.2140]   ITU, "B-ISDN ATM Adaptation Layer - Service Specific
+              Coordination Function for Signalling at the Network Node
+              Interface (SSCF at NNI)," ITU-T Recommendation Q.2140,
+              ITU-T Telecommunication Standardization Sector of ITU
+              (February 1995).
+
+   [Q.2210]   ITU, "Message Transfer Part Level 3 Functions and Messages
+              Using the Services of ITU-T Recommendation Q.2140," ITU-T
+              Recommendation Q.2210, ITU-T Telecommunication
+              Standardization Sector of ITU (July 1996).
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
+              Zhang, L., and V. Paxson, "Stream Control Transmission
+              Protocol", RFC 2960, October 2000.
+
+
+
+
+
+George, et al.              Standards Track                    [Page 50]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+   [RFC3309]  Stone, J., Stewart, R., and D. Otis, "Stream Control
+              Transmission Protocol (SCTP) Checksum Change", RFC 3309,
+              September 2002.
+
+   [RFC3788]  Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
+              Considerations for Signaling Transport (SIGTRAN)
+              Protocols", RFC 3788, June 2004.
+
+   [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).
+
+9.2.  Informative References
+
+   [M2UA]     K. Morneault, et. al., "Signaling System 7 (SS7) Message
+              Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
+              Internet Engineering Task Force - Signalling Transport
+              Working Group (September, 2002).
+
+   [Q.700]    ITU, "Introduction to CCITT Signalling System No. 7,"
+              ITU-T Recommendation Q.700, ITU-T Telecommunication
+              Standardization Sector of ITU (March 1993).
+
+   [Q.701]    ITU, "Functional Description of the Message Transfer Part
+              (MTP) of Signalling System No. 7," ITU-T Recommendation
+              Q.701, ITU-T Telecommunication Standardization Sector of
+              ITU (March 1993).
+
+   [Q.702]    ITU, "Signalling Data Link," ITU-T Recommendation Q.702,
+              ITU-T Telecommunication Standardization Sector of ITU
+              (November 1988).
+
+   [Q.705]    ITU, "Signalling System No. 7 - Signalling Network
+              Structure," ITU-T Recommendation Q.705, ITU-T
+              Telecommunication Standardization Sector of ITU (March
+              1993).
+
+   [RFC2719]  Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
+              L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp,
+              "Framework Architecture for Signaling Transport", RFC
+              2719, October 1999.
+
+
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 51]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+Authors' Addresses
+
+   Tom George
+   Plano, TX
+   USA
+
+   Phone: +1-972-985-4594
+   EMail: tgeorge_tx@verizon.net
+
+   Brian Bidulock
+   OpenSS7 Corporation
+   1469 Jeffreys Crescent
+   Edmonton, AB  T6L 6T1
+   Canada
+
+   Phone: +1-780-490-1141
+   EMail: bidulock@openss7.org
+
+   Ram Dantu, Ph.D.
+   Assistant Professor
+   Department of Computer Science
+   University of North Texas
+   Denton, TX 76203
+   USA
+
+   Phone: +1-940-565-2822
+   EMail: rdantu@unt.edu
+
+   Hanns Juergen Schwarzbauer
+   SIEMENS AG
+   Hofmannstr. 51
+   81359 Munich
+   Germany
+
+   Phone: +49-89-722-24236
+   EMail: HannsJuergen.Schwarzbauer@Siemens.com
+
+   Ken Morneault
+   Cisco Systems Inc.
+   13615 Dulles Technology Drive
+   Herndon, VA 20171
+   USA
+
+   Phone: +1-703-484-3323
+   EMail: kmorneau@cisco.com
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 52]
+
+RFC 4165      SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+George, et al.              Standards Track                    [Page 53]
+