rfc3331.txt

RFC 的详细文档！

   -  network-level fault tolerance through the 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

   There are scenarios without redundancy requirements and scenarios in
   which redundancy is supported below the transport layer.  In these
   cases, the SCTP functions above MAY NOT be a requirement and TCP can
   be used as the underlying common transport protocol.

1.3.2  ASP Fail-over Model and Terminology

   The M2UA layer supports ASP fail-over functions in order to support a
   high availability of call and transaction processing capability.  All
   MTP2-User messages incoming to a SGP from the SS7 network are
   assigned to the unique Application Server, based on the Interface
   Identifier of the message.

   The M2UA layer supports a n+k redundancy model (active-standby, load
   sharing, broadcast) where n 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.  Note that 1+1 active/standby redundancy
   is a subset of this model.  A simplex 1+0 model is also supported as
   a subset, with no ASP redundancy.

1.3.3  Client/Server Model

   It is recommended that the SGP and ASP be able to support both client
   and server operation.  The peer endpoints using M2UA 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.

   The SCTP and TCP Registered User Port Number Assignment for M2UA is
   2904.

1.4  Services Provided by the M2UA Adaptation Layer

   The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
   point in the IP network, so that the M2UA protocol layer is required
   to provide the equivalent set of services to its users as provided by
   the MTP Level 2 to MTP Level 3.







Morneault, et. al.          Standards Track                     [Page 7]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


1.4.1  Support for MTP Level 2 / MTP Level 3 interface boundary

   M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that
   enables a seamless, or as seamless as possible, operation of the
   MTP2-User peers in the SS7 and IP domains.  An example of the
   primitives that need to be supported can be found in [10].

1.4.2  Support for communication between Layer Management modules on SG
       and MGC

   The M2UA layer needs to provide some messages that will facilitate
   communication between Layer Management modules on the SG and MGC.  To
   facilitate reporting of errors that arise because of the backhauling
   MTP Level 3 scenario, the following primitive is defined:

   M-ERROR

   The M-ERROR message is used to indicate an error with a received M2UA
   message (e.g., an interface identifier value is not known to the SG).

1.4.3  Support for management of active associations between SG and MGC

   The M2UA layer on the SG keeps the state of the configured ASPs.  A
   set of primitives between M2UA layer and the Layer Management are
   defined below to help the Layer Management manage the association(s)
   between the SG and the MGC.  The M2UA layer can be instructed by the
   Layer Management to establish a SCTP association to a peer M2UA node.
   This procedure can be achieved using the M-SCTP ESTABLISH primitive.

   M-SCTP_ESTABLISH

   The M-SCTP_ESTABLISH primitive is used to request, indicate and
   confirm the establishment of a SCTP association to a peer M2UA node.

   M-SCTP_RELEASE

   The M-SCTP_RELEASE primitives are used to request, indicate, and
   confirm the release of a SCTP association to a peer M2UA node.

   The M2UA layer MAY also need to inform the status of the SCTP
   association(s) to the Layer Management.  This can be achieved using
   the following primitive.

   M-SCTP_STATUS

   The M-SCTP_STATUS primitive is used to request and indicate the
   status of underlying SCTP association(s).




Morneault, et. al.          Standards Track                     [Page 8]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


   The Layer Management MAY need to inform the M2UA layer of an AS/ASP
   status (i.e., failure, active, etc.), so that messages can be
   exchanged between M2UA layer peers to stop traffic to the local M2UA
   user.  This can be achieved using the following primitive.

   M-ASP_STATUS

   The ASP status is stored inside the M2UA layer on both the SG and MGC
   sides.  The M-ASP_STATUS primitive can be used by Layer Management to
   request the status of the Application Server Process from the M2UA
   layer.  This primitive can also be used to indicate the status of the
   Application Server Process.

   M-ASP_MODIFY

   The M-ASP_MODIFY primitive can be used by Layer Management to modify
   the status of the Application Server Process.  In other words, the
   Layer Management on the ASP side uses this primitive to initiate the
   ASPM procedures.

   M-AS_STATUS

   The M-AS_STATUS primitive can be used by Layer Management to request
   the status of the Application Server.  This primitive can also be
   used to indicate the status of the Application Server.

1.5  Functions Provided by the M2UA Layer

1.5.1  Mapping

   The M2UA layer MUST maintain a map of an Interface ID to a physical
   interface on the Signalling Gateway.  A physical interface would be a
   V.35 line, T1 line/time slot, E1 line/time slot, etc.  The M2UA layer
   MUST also maintain a map of the Interface Identifier to SCTP
   association and to the related stream within the association.

   The SGP maps an Interface Identifier to an SCTP association/stream
   only when an ASP sends an ASP Active message for a particular
   Interface Identifier.  It must be noted, however, that this mapping
   is dynamic and could change at any time due to a change of ASP state.
   This mapping could even temporarily be invalid, for example during
   fail-over of one ASP to another.  Therefore, the SGP MUST maintain
   the states of AS/ASP and reference them during the routing of any
   messages to an AS/ASP.

   Note that only one SGP SHOULD provide Signalling Link Terminal
   services to an SS7 link.  Therefore, within an SG, an Application
   Server SHOULD be active for only one SGP at any given point in time.



Morneault, et. al.          Standards Track                     [Page 9]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


   An example of the logical view of the relationship between an SS7
   link, Interface Identifier, AS and ASP in an SGP is shown below:

               /-------------------------------------------------+
              /   /----------------------------------------------|--+
             /   /                                               v  |
            /   /    +----+             act+-----+   +-------+ -+--+|-+-
   SS7 link1-------->|IID |-+          +-->| ASP |-->| Assoc |      v
              /      +----+ |  +----+  |   +-----+   +-------+ -+--+--+-
             /              +->| AS |--+                        Streams
            /        +----+ |  +----+   stb+-----+
   SS7 link2-------->|IID |-+              | ASP |
                     +----+                +-----+

   where IID = Interface Identifier

   A SGP MAY support more than one AS.  An AS MAY support more than one
   Interface Identifier.

1.5.2  Support for the management of SCTP associations between the SGPs
       and ASPs

   The M2UA layer at the SG maintains the availability state of all
   configured ASPs, in order to manage the SCTP associations and the
   traffic between the SG and ASPs.  As well, the active/inactive state
   of remote ASP(s) are also maintained.  The Active ASP(s) are the
   one(s) currently receiving traffic from the SG.

   The M2UA layer MAY be instructed by local management to establish an
   SCTP association to a peer M2UA node.  This can be achieved using the
   M-SCTP_ESTABLISH primitive to request, indicate and confirm the
   establishment of an SCTP association with a peer M2UA node.

   The M2UA layer MAY also need to inform local management of the status
   of the underlying SCTP associations using the M-SCTP_STATUS request
   and the indication primitive.  For example, the M2UA MAY inform local
   management of the reason for the release of an SCTP association,
   determined either locally within the M2UA layer or by a primitive
   from the SCTP.

   Also the M2UA layer may need to 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.








Morneault, et. al.          Standards Track                    [Page 10]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


1.5.3 Status of ASPs

   The M2UA layer on the SG MUST maintain the state of the ASPs it is
   supporting.  The state of an ASP changes because of the reception of
   peer-to-peer messages (ASPM messages as described in Section 3.3.2)
   or the reception of indications from the local SCTP association.  The
   ASP state transition procedures are described in Section 4.3.1.

   At a SGP, an Application Server list MAY contain active and inactive
   ASPs to support ASP fail-over procedures.  When, for example, both a
   primary and a backup ASP are available, the M2UA peer protocol is
   required to control which ASP is currently active.  The ordered list
   of ASPs within a logical Application Server is kept updated in the
   SGP to reflect the active Application Server Process.

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

1.5.4  SCTP Specifics

1.5.4.1  SCTP Stream Management

   SCTP allows a user specified number of streams to be opened during
   initialization of the association.  It is the responsibility of the
   M2UA layer to ensure proper management of these streams.  Because of
   the unidirectional nature of streams, a M2UA layer is not aware of
   the stream information from its peer M2UA layer.  For this reason,
   the Interface Identifier is in the M2UA message header.

   The use of SCTP streams within M2UA is recommended in order to
   minimize transmission and buffering delay, thereby, improving the
   overall performance and reliability of the signalling elements.  A
   separate SCTP stream can be used for each SS7 link.  Or, an
   implementation may choose to split the SS7 link across several
   streams based on SLS.  This method may be of particular interest for
   high speed SS7 links (MTP3b) since high speed links have a 24-bit
   sequence number and the stream sequence number is 16-bits.

   SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
   messages (see Section 3) since stream '0' SHOULD only be used for ASP
   Management (ASPM) messages (see Section 4.3.3).









Morneault, et. al.          Standards Track                    [Page 11]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


1.5.5  Seamless SS7 Network Management Interworking

   The M2UA layer on the SGP SHOULD pass an indication of unavailability
   of the M2UA-User (MTP3) to the local Layer Management, if the
   currently active ASP moves from the ACTIVE state.  The actions taken
   by M2UA on the SGP with regards to MTP Level 2 should be in
   accordance with the appropriate MTP specifications.

1.5.6  Flow Control / Congestion

   It is possible for the M2UA layer to be informed of the IP network
   congestion onset and abatement by means of an implementation
   dependent function (i.e. an indication from the SCTP).  The handling
   of this congestion indication by M2UA is implementation dependent.
   However, the actions taken by the SG should be in accordance with the
   appropriate MTP specification and should enable SS7 functionality
   (e.g. flow control) to be correctly maintained.

1.5.7  Audit of SS7 Link State

   After a fail-over of one ASP to another ASP, it may be necessary for
   the M2UA on the ASP to audit the current SS7 link state to ensure
   consistency.  The M2UA on the SGP would respond to the audit request
   with information regarding the current state of the SS7 link (i.e.
   in-service, out-of-service, congestion state, LPO/RPO state).

1.6  Definition of the M2UA Boundaries

1.6.1  Definition of the M2UA / MTP Level 3 boundary

   DATA
   ESTABLISH
   RELEASE
   STATE
   DATA RETRIEVAL
   DATA RETRIEVAL COMPLETE

1.6.2  Definition of the M2UA / MTP Level 2 boundary

   DATA
   ESTABLISH
   RELEASE
   STATE
   DATA RETRIEVAL
   DATA RETRIEVAL COMPLETE






Morneault, et. al.          Standards Track                    [Page 12]

RFC 3331             SS7 MTP2 User Adaptation Layer       September 2002


1.6.3  Definition of the Lower Layer Boundary between M2UA and SCTP