draft-ietf-sigtran-m2pa-02.txt

No7信令,我需要交换类似的代码, 请店长审核,谢谢了,急着交换,谢谢

value to MTP3 in the BSNT indication. In the same way, the remote end
also detects its BSNT. The MTP3 layers exchange BSNT values through
the XCO/XCA messages. The BSNT received from the other end is called
the FSNC. When MTP3 receives the FSNC from the other end, MTP3
retrieves all the unsent and unacknowledged messages starting with
sequence number (FSNC + 1).  This is accomplished through a Retrieval
Request and FSNC request. After all the messages are sent from M2PA to
MTP3, M2PA sends a Retrieval Complete indication to MTP3.

As an example of how the BSNT is determined, suppose the following
SSNs had been received by SCTP on the Data Stream when it is time to
do the changeover procedure: 1-10, 13, 14, 16. Then M2PA tells its
upper layer that the last message it received (the BSNT) was 10. SCTP
has not delivered 13, 14, and 16 to M2PA because to do so would
violate ordered delivery within the stream. The value of 10 is
transmitted to the remote end by MTP3 in the XCO/XCA message. So the
remote end will retransmit 11-16 on an alternate link.

If there are any messages on the SCTP receive queue, M2PA SHOULD
receive these messages and deliver them to MTP3. Note that SCTP does
not deliver incoming messages after the first gap (if any) in the
SSNs, since this would violate ordered delivery within the stream. In
the example above, this would mean that messages 1-10 SHOULD be
received. Otherwise, these unreceived messages might be lost, since
SCTP might have acknowledged them.

Note that the sequence numbers and messages requested by MTP3 may be
obtained by M2PA from SCTP via the Communication Lost primitive [5].
Retrieval of messages is an optional feature in SCTP. To perform data
retrieval, it is necessary that this option be implemented, and that
the SSNs of the messages are identified. SCTP must retain the messages
for retrieval by MTP3/M2PA whenever an association is aborted. SCTP
must be able to return messages to M2PA so that M2PA can perform
retrieval for MTP3. There are various ways that this can be
implemented, such as:

   (1) SCTP provides a way for M2PA to request retrieval of messages
       for a specified stream and SSN(s).

   (2) SCTP retrieves all messages and identifies the stream and SSN
       of each message. M2PA then must select the appropriate messages
       to pass up to MTP3.

George, et al                                                [Page 29]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001

M2PA must be able to respond to the BSNT request from MTP3. There are
various ways of implementing this, such as having SCTP provide the
BSNT.

It is helpful for M2PA to have access to the first and last SSN in
SCTP's transmission queue. This information could be used to determine
if the FSNC received from the remote end is a valid value.


If M2PA receives a Retrieve BSNT request from MTP3, M2PA shall respond
with the BSNT indication. The BSNT value is the SCTP stream sequence
number of the last message received by SCTP User Data stream before
any gaps in the stream sequence numbers.

(Note that any messages with stream sequence number greater than this
BSNT value have been acknowledged by the receiving SCTP, but have not
been passed up to M2PA. These messages are discarded by the receiving
SCTP and are not delivered to the upper layer M2PA. Therefore these
messages should be retransmitted by the far end on the alternate
link.)

If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA
shall retrieve from SCTP in order and deliver to MTP3:

   (a) any transmitted User Data messages beginning with the first
       unacknowledged message with stream sequence number greater
       than FSNC.

   (b) any untransmitted User Data messages in SCTP.

   (c) any untransmitted User Data messages M2PA has not delivered
       to SCTP for transmission.

Then M2PA shall send the Retrieval Complete indication to MTP3.

For emergency changover, 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 SCTP in order and deliver to MTP3:

   (a) any untransmitted User Data messages in SCTP.

   (b) any untransmitted User Data messages M2PA has not delivered
       to SCTP for transmission.

Then M2PA shall send the Retrieval Complete indication to MTP3.

Note: The changeover procedure makes it impossible for M2PA to have
multiple User Data streams in a direction for one link. Buffer
updating would have to be done for each User Data stream separately to
avoid duplication of messages. But MTP3 provides for only one XCO
message for sending the last-received SSN.

George, et al                                                [Page 30]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001


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 [1][2]. Communications
between M2PA and SCTP are named using SCTP terminology.


5.1  Link Initialization (Alignment)

An example of the message flow to bring an SS7 link in service is
shown below. Alignment is done by both ends of the link. To simplify the
diagram, alignment is shown on one end only. It is assumed in this
example that SCTP has been initialized.


































George, et al                                                [Page 31]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001


    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

     Out of Service
     <------------

     Emergency OR
     Emergency Ceases
     ------------>

     Start
     ------------>

                 Associate
                 ------------>

                             (SCTP Association
                              procedure)

                 Communication Up        Communication Up
                 <------------           ------------>


Even though the SCTP association is established, it is important that
M2PA not send MTP3 data at this point. It must be confirmed that both
ends of the link are ready for traffic. Otherwise, messages could be
lost. The endpoints must exchange In Service messages.


    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Get SRTT Report
                 ------------>

                 Link Status In Service
                 ------------------------------------>

                                Link Status In Service
                 <------------------------------------

     In Service                                      In Service
     <------------                                   ------------>


At this point, MTP3 may begin sending data messages.






George, et al                                                [Page 32]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001



5.2  Message Transmission and Reception

Messages are transmitted using the Data Request primitive from MTP3 to
M2PA. The diagram 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
                                                     ------------>


5.3  Link Status Indication

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
     <------------










George, et al                                                [Page 33]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001




5.4  Link Status Message (Processor Outage)

This example 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 in
[2].


    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

             M2PA detects 
             Local Processor 
             Outage

                 Link Status
                 Processor Outage
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Remote Processor
                                                  Outage
                                                     ------------>

                 Link Status
                 Processor Outage
                 Ended
                 ------------>

                             (SCTP sends message)

                                         Receive
                                         ------------>

                                                  Remote Processor
                                                  Outage Ceases
                                                     ------------>









George, et al                                                [Page 34]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001


5.5  Level 2 Flow Control

This illustrates the Level 2 Flow Control procedure. In the first
diagram, congestion ceases before timer T6 expires. The second diagram
shows the case where T6 expires.


    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----

                 Implementation dependent 
                 indication of receive 
                 congestion onset
                 <------------

                 Link Status Busy
                 ------------------------------------>

                                                    Start 
                                                    Timer T6

                 Implementation dependent 
                 indication of receive 
                 congestion abatement
                 <------------

                 Link Status Busy Ended
                 ------------------------------------>

                                                    Stop
                                                    Timer T6





















George, et al                                                [Page 35]


Internet Draft  SS7 MTP2-User Peer-to-Peer Adaptation Layer   Mar 2001


    MTP3        M2PA        SCTP        SCTP        M2PA        MTP3
    ----        ----        ----        ----        ----        ----