rfc3332.txt

RFC 的详细文档！

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


      - Explicit packet-oriented delivery (not stream-oriented),
      - Sequenced delivery of user messages within multiple streams,
        with an option for order-of-arrival delivery of individual
        user messages,
      - Optional multiplexing of user messages into SCTP datagrams,
      - Network-level fault tolerance through support of multi-homing
        at either or both ends of an association,
      - Resistance to flooding and masquerade attacks, and
      - Data segmentation to conform to discovered path MTU size.

   Under certain scenarios, such as back-to-back connections without
   redundancy requirements, the SCTP functions above might not be a
   requirement and TCP MAY be used as the underlying common transport
   protocol.

1.3.2 Services Provided by the M3UA Layer

   The M3UA Layer at an ASP or IPSP provides the equivalent set of
   primitives at its upper layer to the MTP3-Users as provided by the
   MTP Level 3 to its local MTP3-Users at an SS7 SEP.  In this way, the
   ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected
   MTP3 services are offered remotely from an MTP3 Layer at an SGP, and
   not by a local MTP3 layer.  The MTP3 layer at an SGP may also be
   unaware that its local users are actually remote user parts over
   M3UA.  In effect, the M3UA extends access to the MTP3 layer services
   to a remote IP-based application.  The M3UA layer does not itself
   provide the MTP3 services. However, in the case where an ASP is
   connected to more than one SG, the M3UA layer at an ASP should
   maintain the status of configured SS7 destinations and route messages
   according to the availability and congestion status of the routes to
   these destinations via each SG.

   The M3UA layer may also be used for point-to-point signalling between
   two IP Server Processes (IPSPs).  In this case, the M3UA layer
   provides the same set of primitives and services at its upper layer
   as the MTP3. However, in this case the expected MTP3 services are not
   offered remotely from an SGP.  The MTP3 services are provided but the
   procedures to support these services are a subset of the MTP3
   procedures due to the simplified point-to-point nature of the IPSP to
   IPSP relationship.











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


1.3.2.1 Support for the Transport of MTP3-User Messages

   The M3UA layer provides the transport of MTP-TRANSFER primitives
   across an established SCTP association between an SGP and an ASP or
   between IPSPs.

   At an ASP, in the case where a destination is reachable via multiple
   SGPs, the M3UA layer must also choose via which SGP the message is to
   be routed or support load balancing across the SGPs, minimizing
   missequencing.

   The M3UA layer does not impose a 272-octet signalling information
   field (SIF) length limit as specified by the SS7 MTP Level 2 protocol
   [7,8,9]. Larger information blocks can be accommodated directly by
   M3UA/SCTP, without the need for an upper layer segmentation/re-
   assembly procedure as specified in recent SCCP or ISUP versions.
   However, in the context of an SG, the maximum 272-octet block size
   must be followed when interworking to a SS7 network that does not
   support the transfer of larger information blocks to the final
   destination.  This avoids potential ISUP or SCCP fragmentation
   requirements at the SGPs.  The provisioning and configuration of the
   SS7 network determines the restriction placed on the maximum block
   size.  Some configurations (e.g., Broadband MTP [21]) may permit
   larger block sizes.

1.3.2.2 Native Management Functions

   The M3UA layer provides the capability to indicate errors associated
   with received M3UA messages and to notify, as appropriate, local
   management and/or the peer M3UA.

1.3.2.3 Interworking with MTP3 Network Management Functions

   At the SGP, the M3UA layer provides interworking with MTP3 management
   functions to support seamless operation of the user SCN signalling
   applications in the SS7 and IP domains.  This includes:

   - Providing an indication to MTP3-Users at an ASP that a destination
     in the SS7 network is not reachable.

   - Providing an indication to MTP3-Users at an ASP that a destination
     in the SS7 network is now reachable.

   - Providing an indication to MTP3-Users at an ASP that messages to a
     destination in the SS7 network are experiencing SS7 congestion.






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


   - Providing an indication to the M3UA layer at an ASP that the routes
     to a destination in the SS7 network are restricted.

   - Providing an indication to MTP3-Users at an ASP that a MTP3-User
     peer is unavailable.

   The M3UA layer at an ASP keeps the state of the routes to remote SS7
   destinations and may initiate an audit of the availability, the
   restricted or the congested state of remote SS7 destinations.  This
   information is requested from the M3UA layer at the SGP.

   The M3UA layer at an ASP may also indicate to the SG that the M3UA
   layer itself or the ASP or the ASP's Host is congested.

1.3.2.4 Support for the Management of SCTP Associations between the SGP
        and ASPs.

   The M3UA layer at the SGP maintains the availability state of all
   configured remote ASPs, to manage the SCTP Associations and the
   traffic between the M3UA peers.  As well, the active/inactive and
   congestion state of remote ASPs is maintained.

   The M3UA layer MAY be instructed by local management to establish an
   SCTP association to a peer M3UA node.  This can be achieved using the
   M-SCTP_ESTABLISH primitives (See Section 1.6.3 for a description of
   management primitives.) to request, indicate and confirm the
   establishment of an SCTP association with a peer M3UA node.  In order
   to avoid redundant SCTP associations between two M3UA peers, one side
   (client) SHOULD be designated to establish the SCTP association, or
   M3UA configuration information maintained to detect redundant
   associations (e.g., via knowledge of the expected local and remote
   SCTP endpoint addresses).

   Local management MAY request from the M3UA layer the status of the
   underlying SCTP associations using the M-SCTP_STATUS request and
   confirm primitives.  Also, the M3UA MAY autonomously inform local
   management of the reason for the release of an SCTP association,
   determined either locally within the M3UA layer or by a primitive
   from the SCTP.

   Also the M3UA layer MAY inform the local management of the change in
   status of an ASP or AS.  This MAY be achieved using the M-ASP_STATUS
   request or M-AS_STATUS request primitives.








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


1.3.2.5 Support for the Management of Connections to Multiple SGPs

   As shown in Figure 1 an ASP may be connected to multiple SGPs. In
   such a case a particular SS7 destination may be reachable via more
   than one SGP and/or SG, i.e., via more than one route. As MTP3 users
   only maintain status on a destination and not on a route basis, the
   M3UA layer must maintain the status (availability, restriction,
   and/or congestion of route to destination) of the individual routes,
   derive the overall availability or congestion status of the
   destination from the status of the individual routes, and inform the
   MTP3 users of this derived status whenever it changes.

1.4 Functional Areas

1.4.1 Signalling Point Code Representation

   For example, within an SS7 network, a Signalling Gateway might be
   charged with representing a set of nodes in the IP domain into the
   SS7 network for routing purposes.  The SG itself, as a signalling
   point in the SS7 network, might also be addressable with an SS7 Point
   Code for MTP3 Management purposes. The SG Point Code might also be
   used for addressing any local MTP3-Users at the SG such as a local
   SCCP layer.

   An SG may be logically partitioned to operate in multiple SS7 network
   appearances.  In such a case, the SG could be addressable with a
   Point Code in each network appearance, and represents a set of nodes
   in the IP domain into each SS7 network.  Alias Point Codes [8] may
   also be used within an SG network appearance.

   Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
   remote AS/ASP states of each SGP SHOULD be coordinated across all the
   SGPs.  Rerouting of traffic between the SGPs MAY also be supported.

   Application Servers can be represented under the same Point Code of
   the SG, their own individual Point Codes or grouped with other
   Application Servers for Point Code preservation purposes.  A single
   Point Code may be used to represent the SG and all the Application
   Servers together, if desired.

   If an ASP or group of ASPs is available to the SS7 network via more
   than one SG, each with its own Point Code, the ASP(s) will typically
   be represented by a Point Code that is separate from any SG Point
   Code. This allows, for example, these SGs to be viewed from the SS7
   network as "STPs", each having an ongoing "route" to the same ASP(s).
   Under failure conditions where the ASP(s) become(s) unavailable from
   one of the SGs, this approach enables MTP3 route management messaging
   between the SG and SS7 network, allowing simple SS7 rerouting through



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


   an alternate SG without changing the Destination Point Code Address
   of SS7 traffic to the ASP(s).

   Where a particular AS can be reached via more than one SGP, the
   corresponding Routing Keys in the SGPs should be identical.  (Note:
   It is possible for the SGP Routing Key configuration data to be
   temporarily out-of-sync during configuration updates).

                              +--------+
                              |        |
                 +------------+  SG 1  +--------------+
     +-------+   |  SS7 links | "STP"  |  IP network  |     ----
     |  SEP  +---+            +--------+              +---/      \
     |   or  |                    |*                      | ASPs  |
     |  STP  +---+            +--------+              +---\      /
     +-------+   |            |        |              |     ----
                 +------------+  SG 2  +--------------+
                              | "STP"  |
                              +--------+

                    Figure 1  Example with mated SGs

   * Note:.  SG-to-SG communication (i.e., "C-links") is recommended for
   carrier grade networks, using an MTP3 linkset or an equivalent, to
   allow rerouting between the SGs in the event of route failures. Where
   SGPs are used, inter-SGP communication might be used.  Inter-SGP
   protocol is outside of the scope of this document.

   The following example shows a signalling gateway partitioned into two
   network appearances.

                                  SG
     +-------+              +---------------+
     |  SEP  +--------------| SS7 Ntwk |M3UA|              ----
     +-------+   SS7 links  |   "A"    |    |            /      \
                            |__________|    +-----------+  ASPs  |
                            |          |    |            \      /
     +-------+              | SS7 Ntwk |    |              ----
     |  SEP  +--------------+   "B"    |    |
     +-------+              +---------------+

                    Figure 2  Example with multiple Network









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


1.4.2 Routing Contexts and Routing Keys

1.4.2.1 Overview

   The distribution of SS7 messages between the SGP and the Application
   Servers is determined by the Routing Keys and their associated
   Routing Contexts.  A Routing Key is essentially a set of SS7
   parameters used to filter SS7 messages, whereas the Routing Context
   parameter is a 4-byte value (integer) that is associated to that
   Routing Key in a 1:1 relationship.  The Routing Context therefore can
   be viewed as an index into a sending node's Message Distribution
   Table containing the Routing Key entries.

   Possible SS7 address/routing information that comprise a Routing Key
   entry includes, for example, the OPC, DPC, SIO found in the MTP3
   routing label, or MTP3-User specific fields (such as the ISUP CIC,
   SCCP subsystem number).  Some example Routing Keys are: the DPC
   alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
   DPC/SSN combination.  The particular information used to define an
   M3UA Routing Key is application and network dependent, and none of
   the above examples are mandated.

   An Application Server Process may be configured to process signalling
   traffic related to more than one Application Server, over a single
   SCTP Association.  In ASP Active and ASP Inactive management
   messages, the signalling traffic to be started or stopped is
   discriminated by the Routing Context parameter.  At an ASP, the
   Routing Context parameter uniquely identifies the range of signalling
   traffic associated with each Application Server that the ASP is
   configured to receive.

1.4.2.2 Routing Key Limitations

   Routing Keys SHOULD be unique in the sense that each received SS7
   signalling message SHOULD have a full or partial match to a single
   routing result. It is not necessary for the parameter range values
   within a particular Routing Key to be contiguous.  For example, an AS
   could be configured to support call processing for multiple ranges of
   PSTN trunks that are not represented by contiguous CIC values.