rfc3332.txt

RFC 的详细文档！

   translated to MTP-TRANSFER request primitives, and sent to the local
   M3UA-resident message distribution function for ongoing routing to
   the final IP destination.  Messages received from the local M3UA
   network address translation and mapping function as MTP-TRANSFER
   indication primitives are sent to the MTP Level 3 upper layer
   interface as MTP-TRANSFER request primitives for ongoing MTP Level 3
   routing to an SS7 SEP.  For the purposes of providing SS7 network
   status information the NIF also delivers MTP-PAUSE, MTP-RESUME and
   MTP-STATUS indication primitives received from the MTP Level 3 upper
   layer interface to the local M3UA-resident management function. In
   addition, as an implementation and network option, restricted
   destinations are communicated from MTP network management to the
   local M3UA-resident management function.



Sidebottom, et. al.         Standards Track                    [Page 18]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


1.5.2  Example 2: SCCP Transport between IPSPs

         ********    IP    ********
         * IPSP *          * IPSP *
         ********          ********

         +------+          +------+
         |SCCP- |          |SCCP- |
         | User |          | User |
         +------+          +------+
         | SCCP |          | SCCP |
         +------+          +------+
         | M3UA |          | M3UA |
         +------+          +------+
         | SCTP |          | SCTP |
         +------+          +------+
         |  IP  |          |  IP  |
         +------+          +------+
             |________________|

   This example shows an architecture where no Signalling Gateway is
   used. In this example, SCCP messages are exchanged directly between
   two IP-resident IPSPs with resident SCCP-User protocol instances,
   such as RANAP or TCAP.  SS7 network interworking is not required,
   therefore there is no MTP3 network management status information for
   the SCCP and SCCP-User protocols to consider.  Any MTP-PAUSE, MTP-
   RESUME or MTP-STATUS indications from the M3UA layer to the SCCP
   layer should consider the status of the SCTP Association and
   underlying IP network and any congestion information received from
   the remote site.





















Sidebottom, et. al.         Standards Track                    [Page 19]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP

      ********   SS7   *****************   IP   ********
      * SEP  *---------*               *--------*      *
      *  or  *         *      SGP      *        * ASP  *
      * STP  *         *               *        *      *
      ********         *****************        ********

      +------+         +---------------+        +------+
      | SCCP-|         |     SCCP      |        | SCCP-|
      | User |         +---------------+        | User |
      +------+           |   _____   |          +------+
      | SCCP |           |  |     |  |          | SCCP |
      +------+         +------+-+------+        +------+
      | MTP3 |         | MTP3 | | M3UA |        | M3UA |
      +------|         +------+ +------+        +------+
      | MTP2 |         | MTP2 | | SCTP |        | SCTP |
      +------+         +------+ +------+        +------+
      |  L1  |         |  L1  | |  IP  |        |  IP  |
      +------+         +------+ +------+        +------+
          |_______________|         |______________|

   STP - SS7 Signalling Transfer Point

   In this example, the SGP contains an instance of the SS7 SCCP
   protocol layer that may, for example, perform the SCCP Global Title
   Translation (GTT) function for messages logically addressed to the SG
   SCCP.  If the result of a GTT for an SCCP message yields an SS7 DPC
   or DPC/SSN address of an SCCP peer located in the IP domain, the
   resulting MTP-TRANSFER request primitive is sent to the local M3UA-
   resident network address translation and mapping function for ongoing
   routing to the final IP destination.

   Similarly, the SCCP instance in an SGP can perform the SCCP GTT
   service for messages logically addressed to it from SCCP peers in the
   IP domain.  In this case, MTP-TRANSFER indication primitives are sent
   from the local M3UA-resident network address translation and mapping
   function to the SCCP for GTT.  If the result of the GTT yields the
   address of an SCCP peer in the SS7 network then the resulting MTP-
   TRANSFER request primitive is given to the MTP3 for delivery to an
   SS7-resident node.

   It is possible that the above SCCP GTT at the SGP could yield the
   address of an SCCP peer in the IP domain and the resulting MTP-
   TRANSFER request primitive would be sent back to the M3UA layer for
   delivery to an IP destination.





Sidebottom, et. al.         Standards Track                    [Page 20]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


   For internal SGP modeling purposes, this may be accomplished with the
   use of an implementation-dependent nodal interworking function within
   the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
   request/indication messages to/from both the MTP3 and the M3UA layer,
   based on the SS7 DPC or DPC/SSN address information.  This nodal
   interworking function has no visible peer protocol with either the
   ASP or SEP.

   Note that the services and interface provided by the M3UA layer are
   the same as in Example 1 and the functions taking place in the SCCP
   entity are transparent to the M3UA layer.  The SCCP protocol
   functions are not reproduced in the M3UA protocol.

1.6 Definition of M3UA Boundaries

1.6.1 Definition of the Boundary between M3UA and an MTP3-User.

   From ITU Q.701 [7]:

      MTP-TRANSFER request
      MTP-TRANSFER indication
      MTP-PAUSE indication
      MTP-RESUME indication
      MTP-STATUS indication

1.6.2 Definition of the Boundary between M3UA and SCTP

   An example of the upper layer primitives provided by the SCTP are
   provided in Reference [17] Section 10.

1.6.3 Definition of the Boundary between M3UA and Layer Management

   M-SCTP_ESTABLISH request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to establish an SCTP association with its
   peer.

   M-STCP_ESTABLISH confirm
   Direction: M3UA -> LM
   Purpose: ASP confirms to LM that it has established an SCTP
   association with its peer.

   M-SCTP_ESTABLISH indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that a remote ASP has established an SCTP
   association.





Sidebottom, et. al.         Standards Track                    [Page 21]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


   M-SCTP_RELEASE request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to release an SCTP association with its
   peer.

   M-SCTP_RELEASE confirm
   Direction: M3UA -> LM
   Purpose: ASP confirms to LM that it has released SCTP association
   with its peer.

   M-SCTP_RELEASE indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that a remote ASP has released an SCTP
   Association or the SCTP association has failed.

   M-SCTP_RESTART indication
   Direction: M3UA -> LM
   Purpose: M3UA informs LM that an SCTP restart indication has been
   received.

   M-SCTP_STATUS request
   Direction: LM -> M3UA
   Purpose: LM requests M3UA to report the status of an SCTP
   association.

   M-SCTP_STATUS confirm
   Direction: M3UA -> LM
   Purpose: M3UA responds with the status of an SCTP association.


   M-SCTP STATUS indication
   Direction: M3UA -> LM
   Purpose: M3UA reports the status of an SCTP association.

   M-ASP_STATUS request
   Direction: LM -> M3UA
   Purpose: LM requests M3UA to report the status of a local or remote
   ASP.

   M-ASP_STATUS confirm
   Direction: M3UA -> LM
   Purpose: M3UA reports status of local or remote ASP.

   M-AS_STATUS request
   Direction: LM -> M3UA
   Purpose: LM requests M3UA to report the status of an AS.





Sidebottom, et. al.         Standards Track                    [Page 22]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


   M-AS_STATUS confirm
   Direction: M3UA -> LM
   Purpose: M3UA reports the status of an AS.

   M-NOTIFY indication
   Direction: M3UA -> LM
   Purpose: M3UA reports that it has received a Notify message
   from its peer.

   M-ERROR indication
   Direction: M3UA -> LM
   Purpose: M3UA reports that it has received an Error message from
   its peer or that a local operation has been unsuccessful.

   M-ASP_UP request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to start its operation and send an ASP Up
   message to its peer.

   M-ASP_UP confirm
   Direction: M3UA -> LM
   Purpose: ASP reports that is has received an ASP UP Ack message from
   its peer.

   M-ASP_UP indication
   Direction: M3UA -> LM
   Purpose: M3UA reports it has successfully processed an incoming ASP
   Up message from its peer.

   M-ASP_DOWN request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to stop its operation and send an ASP Down
   message to its peer.

   M-ASP_DOWN confirm
   Direction: M3UA -> LM
   Purpose: ASP reports that is has received an ASP Down Ack message
   from its peer.

   M-ASP_DOWN indication
   Direction: M3UA -> LM
   Purpose: M3UA reports it has successfully processed an incoming ASP
   Down message from its peer, or the SCTP association has
   been lost/reset.







Sidebottom, et. al.         Standards Track                    [Page 23]

RFC 3332             SS7 MTP3-User Adaptation Layer       September 2002


   M-ASP_ACTIVE request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to send an ASP Active message to its peer.

   M-ASP_ACTIVE confirm
   Direction: M3UA -> LM
   Purpose: ASP reports that is has received an ASP Active
   Ack message from its peer.

   M-ASP_ACTIVE indication
   Direction: M3UA -> LM
   Purpose: M3UA reports it has successfully processed an incoming ASP
   Active message from its peer.

   M-ASP_INACTIVE request
   Direction: LM -> M3UA
   Purpose: LM requests ASP to send an ASP Inactive message to its
   peer.

   M-ASP_INACTIVE confirm
   Direction: LM -> M3UA
   Purpose: ASP reports that is has received an ASP Inactive
   Ack message from its peer.

   M-ASP_INACTIVE indication
   Direction: M3UA -> LM
   Purpose: M3UA reports it has successfully processed an incoming ASP
   Inactive message from its peer.

   M-AS_ACTIVE indication