rfc3332.txt

RFC 的详细文档！

1.4.2.3 Managing Routing Contexts and Routing Keys

   There are two ways to provision a Routing Key at an SGP.  A Routing
   Key may be configured statically using an implementation dependent
   management interface, or dynamically using the M3UA Routing Key
   registration procedure.





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


   When using a management interface to configure Routing Keys, the
   message distribution function within the SGP is not limited to the
   set of parameters defined in this document.  Other implementation
   dependent distribution algorithms may be used.

1.4.2.4 Message Distribution at the SGP

   To direct messages received from the SS7 MTP3 network to the
   appropriate IP destination, the SGP must perform a message
   distribution function using information from the received MTP3-User
   message.

   To support this message distribution, the SGP might, for example,
   maintain the equivalent of a network address translation table,
   mapping incoming SS7 message information to an Application Server for
   a particular application and range of traffic.  This could be
   accomplished by comparing elements of the incoming SS7 message to
   currently defined Routing Keys in the SGP.

   These Routing Keys could in turn map directly to an Application
   Server that is enabled by one or more ASPs.  These ASPs provide
   dynamic status information regarding their availability, traffic
   handling capability and congestion to the SGP using various
   management messages defined in the M3UA protocol.

   The list of ASPs in an AS is assumed to be dynamic, taking into
   account the availability, traffic handling capability and congestion
   status of the individual ASPs in the list, as well as configuration
   changes and possible failover mechanisms.

   Normally, one or more ASPs are active (i.e., currently processing
   traffic) in the AS but in certain failure and transition cases it is
   possible that there may be no active ASP available.  Broadcast,
   loadsharing and backup scenarios are supported.

   When there is no matching Routing Key entry for an incoming SS7
   message, a default treatment MAY be specified.  Possible solutions
   are to provide a default Application Server at the SGP that directs
   all unallocated traffic to a (set of) default ASP(s), or to drop the
   message and provide a notification to layer management.  The
   treatment of unallocated traffic is implementation dependent.










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


1.4.2.5 Message Distribution at the ASP

   The ASP must choose an SGP to direct a message to the SS7 network.
   This is accomplished by observing the Destination Point Code (and
   possibly other elements of the outgoing message such as the SLS
   value). The ASP must also take into account whether the related
   Routing Context is active or not (See Section 4.3.4.3).

   Implementation Note: Where more than one route (or SGP) is possible
   for routing to the SS7 network, the ASP could, for example, maintain
   a dynamic table of available SGP routes for the SS7 destinations,
   taking into account the SS7 destination
   availability/restricted/congestion status received from the SGP(s),
   the availability status of the individual SGPs and configuration
   changes and failover mechanisms. There is, however, no M3UA messaging
   to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive
   messaging).

   Whenever an SCTP association to an SGP exists, the SGP is assumed to
   be ready for the purposes of responding to M3UA ASPSM messages (Refer
   to Section 3).

1.4.3 SS7 and M3UA Interworking

   In the case of SS7 and M3UA interworking, the M3UA adaptation layer
   is designed to provide an extension of the MTP3 defined user
   primitives.

1.4.3.1 Signalling Gateway SS7 Layers

   The SG is responsible for terminating MTP Level 3 of the SS7
   protocol, and offering an IP-based extension to its users.

   From an SS7 perspective, it is expected that the Signalling Gateway
   transmits and receives SS7 Message Signalling Units (MSUs) to and
   from the PSTN over a standard SS7 network interface, using the SS7
   Message Transfer Part (MTP) [7,8,9] to provide reliable transport of
   the messages.

   As a standard SS7 network interface, the use of MTP Level 2
   signalling links is not the only possibility.  ATM-based High Speed
   Links can also be used with the services of the Signalling ATM
   Adaptation Layer (SAAL) [18,19].

   Note: It is also possible for IP-based interfaces to be present,
   using the services of the MTP2-User Adaptation Layer (M2UA) [27] or
   M2PA [28].




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


   These could be terminated at a Signalling Transfer Point (STP) or
   Signalling End Point (SEP).  Using the services of MTP3, the SG could
   be capable of communicating with remote SS7 SEPs in a quasi-
   associated fashion, where STPs may be present in the SS7 path between
   the SEP and the SG.

1.4.3.2 SS7 and M3UA Interworking at the SG

   The SGP provides a functional interworking of transport functions
   between the SS7 network and the IP network by also supporting the
   M3UA adaptation layer.  It allows the transfer of MTP3-User
   signalling messages to and from an IP-based Application Server
   Process where the peer MTP3-User protocol layer exists.

   For SS7 user part management, it is required that the MTP3-User
   protocols at ASPs receive indications of SS7 signalling point
   availability, SS7 network congestion, and remote User Part
   unavailability as would be expected in an SS7 SEP node.  To
   accomplish this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication
   primitives received at the MTP3 upper layer interface at the SG need
   to be propagated to the remote MTP3-User lower layer interface at the
   ASP.

   MTP3 management messages (such as TFPs or TFAs received from the SS7
   network) MUST NOT be encapsulated as Data message Payload Data and
   sent either from SG to ASP or from ASP to SG.  The SG MUST terminate
   these messages and generate M3UA messages as appropriate.

1.4.3.3 Application Server

   A cluster of application servers is responsible for providing the
   overall support for one or more SS7 upper layers.  From an SS7
   standpoint, a Signalling Point Management Cluster (SPMC) provides
   complete support for the upper layer service for a given point code.
   As an example, an SPMC providing MGC capabilities could provide
   complete support for ISUP (and any other MTP3 user located at the
   point code of the SPMC) for a given point code.

   In the case where an ASP is connected to more than one SGP, the M3UA
   layer must maintain the status of configured SS7 destinations and
   route messages according to availability/congestion/restricted status
   of the routes to these SS7 destinations.

1.4.3.4 IPSP Considerations

   Since IPSPs use M3UA in a point-to-point fashion, there is no concept
   of routing of messages beyond the remote end.  Therefore, SS7 and
   M3UA interworking is not necessary for this model.



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


1.4.4 Redundancy Models

1.4.4.1 Application Server Redundancy

   All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
   Routing Key at an SGP are mapped to an Application Server.

   The Application Server is the set of all ASPs associated with a
   specific Routing Key. Each ASP in this set may be active, inactive or
   unavailable.  Active ASPs handle traffic; inactive ASPs might be used
   when active ASPs become unavailable.

   The failover model supports an "n+k" redundancy model, where "n" ASPs
   is the minimum number of redundant ASPs required to handle traffic
   and "k" ASPs are available to take over for a failed or unavailable
   ASP.  A "1+1" active/backup redundancy is a subset of this model. A
   simplex "1+0" model is also supported as a subset, with no ASP
   redundancy.

1.4.5 Flow Control

   Local Management at an ASP may wish to stop traffic across an SCTP
   association to temporarily remove the association from service or to
   perform testing and maintenance activity.  The function could
   optionally be used to control the start of traffic on to a newly
   available SCTP association.

1.4.6 Congestion Management

   The M3UA layer is informed of local and IP network congestion by
   means of an implementation-dependent function (e.g., an
   implementation dependent indication from the SCTP of IP network
   congestion).

   At an ASP or IPSP, the M3UA layer indicates congestion to local
   MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3
   procedures, to invoke appropriate upper layer responses.

   When an SG determines that the transport of SS7 messages to a
   Signalling Point Management Cluster (SPMC) is encountering
   congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled
   management messages to originating SS7 nodes, per the congestion
   procedures of the relevant MTP3 standard. The triggering of SS7 MTP3
   Management messages from an SG is an implementation-dependent
   function.






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


   The M3UA layer at an ASP or IPSP MAY indicate local congestion to an
   M3UA peer with an SCON message.  When an SG receives a congestion
   message (SCON) from an ASP, and the SG determines that an SPMC is now
   encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled
   management messages to concerned SS7 destinations according to
   congestion procedures of the relevant MTP3 standard.

1.4.7 SCTP Stream Mapping.

   The M3UA layer at both the SGP and ASP also supports the assignment
   of signalling traffic into streams within an SCTP association.
   Traffic that requires sequencing SHOULD be assigned to the same
   stream.  To accomplish this, MTP3-User traffic may be assigned to
   individual streams based on, for example, the SLS value in the MTP3
   Routing Label or the ISUP CIC assignment, subject of course to the
   maximum number of streams supported by the underlying SCTP
   association.

1.4.8 Client/Server Model

   It is recommended that the SGP and ASP be able to support both client
   and server operation. The peer endpoints using M3UA SHOULD be
   configured so that one always takes on the role of client and the
   other the role of server for initiating SCTP associations.  The
   default orientation would be for the SGP to take on the role of
   server while the ASP is the client. In this case, ASPs SHOULD
   initiate the SCTP association to the SGP.

   In the case of IPSP to IPSP communication, the peer endpoints using
   M3UA SHOULD be configured so that one always takes on the role of
   client and the other the role of server for initiating SCTP
   associations.

   The SCTP and TCP Registered User Port Number Assignment for M3UA is
   2905.
















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


1.5 Sample Configuration

1.5.1 Example 1: ISUP Message Transport

   ********   SS7   *****************   IP   ********
   * SEP  *---------*      SGP      *--------* ASP  *
   ********         *****************        ********

   +------+         +---------------+        +------+
   | ISUP |         |     (NIF)     |        | ISUP |
   +------+         +------+ +------+        +------+
   | MTP3 |         | MTP3 | | M3UA |        | M3UA |
   +------|         +------+-+------+        +------+
   | MTP2 |         | MTP2 | | SCTP |        | SCTP |
   +------+         +------+ +------+        +------+
   |  L1  |         |  L1  | |  IP  |        |  IP  |
   +------+         +------+ +------+        +------+
       |_______________|         |______________|


   SEP - SS7 Signalling End Point
   SCTP - Stream Control Transmission Protocol
   NIF - Nodal Interworking Function

   In this example, the SGP provides an implementation-dependent nodal
   interworking function (NIF) that allows the MGC to exchange SS7
   signalling messages with the SS7-based SEP.  The NIF within the SGP
   serves as the interface within the SGP between the MTP3 and M3UA.
   This nodal interworking function has no visible peer protocol with
   either the MGC or SEP.  It also provides network status information
   to one or both sides of the network.

   For internal SGP modeling purposes, at the NIF level, SS7 signalling
   messages that are destined to the MGC are received as MTP-TRANSFER
   indication primitives from the MTP Level 3 upper layer interface,