rfc3057.txt

最新的RFC

     *  SG1 *   SCTP Associations           |         *  ********  *
     *      *_______________________        |         *            *
     ********                       |       |         **************
                                    |       |
     ********                       |       |
     *      *_______________________________|
     *      *                       |
     *  SG2 *    SCTP Associations  |
     *      *____________           |
     *      *            |          |                     Host2
     ********            |          |                 **************
                         |          |_________________*  ********  *
                         |____________________________*  * ASP1 *  *
                                                      *  ********  *
                                                      *            *
                                                      **************
                                                              .
                                                              .
                                                              .

                       Figure 2 - Logical Model Example

   For carrier grade networks, the failure or isolation of a particular
   ASP SHOULD NOT cause stable calls to be dropped.  This implies that
   ASPs need, in some cases, to share the call state or be able to pass
   the call state between each other.  However, this sharing or
   communication of call state information is outside the scope of this
   document.

1.3.4 ASP Fail-over Model and Terminology

   The IUA layer supports ASP fail-over functions in order to support a
   high availability of call processing capability.  All Q.921-User
   messages incoming to an SG are assigned to a unique Application
   Server, based on the Interface Identifier of the message.

   The Application Server is, in practical terms, a list of all ASPs
   configured to process Q.921-User messages from certain Interface
   Identifiers.  One or more ASPs in the list are normally active (i.e.,
   handling traffic) while any others MAY be unavailable or inactive, to
   be possibly used in the event of failure or unavailability of the
   active ASP(s).





Morneault, et al.           Standards Track                     [Page 7]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   The fail-over model supports an n+k redundancy model, where n ASP(s)
   are 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.

   To avoid a single point of failure, it is recommended that a minimum
   of two ASPs be in the list, resident in separate hosts and therefore
   available over different SCTP Associations.  For example, in the
   network shown in Figure 2, all messages from a particular D Channel
   (Interface Identifier) could be sent to ASP1 in Host1 or ASP1 in
   Host2. The AS list at SG1 might look like the following:

      Interface Identifier(s) - Application Server #1
          ASP1/Host1  - State=Up, Active
          ASP1/Host2  - State=Up, Inactive

   In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
   message for the Interface Identifiers registered.  ASP1 in Host2
   would normally be brought to the active state upon failure of, or
   loss of connectivity to, ASP1/Host1.  In this example, both ASPs are
   Up, meaning that the related SCTP association and far-end IUA peer is
   ready.

   The AS List at SG1 might also be set up in load-share mode as shown
   below:

      Interface Identifier(s) - Application Server #1
          ASP1/Host1 - State=Up, Active
          ASP1/Host2 - State=Up, Active

   In this case, both the ASPs would be sent a portion of the traffic.

   In the process of fail-over, it is recommended that in the case of
   ASPs supporting call processing, stable calls do not get released.
   It is possible that calls in transition MAY fail, although measures
   of communication between the ASPs involved can be used to mitigate
   this problem.  For example, the two ASPs MAY share call state via
   shared memory, or MAY use an ASP to ASP protocol to pass call state
   information.  The ASP to ASP protocol is outside the scope of this
   document.

1.3.5  Client/Server Model

   It is recommended that the SG and ASP be able to support both client
   and server operation.  The peer endpoints using IUA SHOULD be
   configured so that one always takes on the role of client and the



Morneault, et al.           Standards Track                     [Page 8]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   other the role of server for initiating SCTP associations.  The
   default orientation would be for the SG to take on the role of server
   while the ASP is the client.  In this case, ASPs SHOULD initiate the
   SCTP association to the SG.

   The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
   is 9900.

1.4  Services Provided by the IUA Layer

1.4.1  Support for transport of Q.921/Q.931 boundary primitives

   In the backhaul scenario, the Q.921/Q.931 boundary primitives are
   exposed.  IUA layer needs to support all of the primitives of this
   boundary to successfully backhaul Q.931.

   This includes the following primitives [1]:

   DL-ESTABLISH

   The DL-ESTABLISH primitives are used to request, indicate and confirm
   the outcome of the procedures for establishing multiple frame
   operation.

   DL-RELEASE

   DL-RELEASE primitives are used to request, indicate, and confirm the
   outcome of the procedures for terminating a previously established
   multiple frame operation, or for reporting an unsuccessful
   establishment attempt.

   DL-DATA

   The DL-DATA primitives are used to request and indicate layer 3
   (Q.931) messages which are to be transmitted, or have been received,
   by the Q.921 layer using the acknowledged information transfer
   service.

   DL-UNIT DATA

   The DL-UNIT DATA primitives are used to request and indicate layer 3
   (Q.931) messages which are to be transmitted, by the Q.921 layer
   using the unacknowledged information transfer service.








Morneault, et al.           Standards Track                     [Page 9]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


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

   It is envisioned that the IUA layer needs to provide some services
   that will facilitate communication between Layer Management modules
   on the SG and MGC.  These primitives are pointed out in [2], which
   are shown below:

   M-TEI STATUS

   The M-TEI STATUS primitives are used to request, confirm and indicate
   the status (assigned/unassigned) of a TEI.

   M-ERROR

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

1.4.3 Support for management of active associations between SG and MGC

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

   M-SCTP ESTABLISH

   The M-SCTP ESTABLISH primitives are used to request, indicate, and
   confirm the establishment of an SCTP association to a peer IUA node.

   M-SCTP RELEASE

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

   The IUA layer MAY also need to inform the status of the SCTP
   associations to the Layer Management.  This can be achieved using the
   M-SCTP STATUS primitive.

   M-SCTP STATUS

   The M-SCTP STATUS primitives are used to request and indicate the
   status of the underlying SCTP association(s).





Morneault, et al.           Standards Track                    [Page 10]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


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

   M-ASP STATUS

   The ASP status is stored inside IUA 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 IUA
   layer.  This primitive can also be used to indicate the status of the
   Application Server Process.

   M-ASP-UP

   The M-ASP-UP primitive can be used by Layer Management to send a ASP
   Up message for the Application Server Process.  It can also be used
   to generate an ASP Up Acknowledgement.

   M-ASP-DOWN

   The M-ASP-DOWN primitive can be used by Layer Management to send a
   ASP Down message for the Application Server Process.  It can also be
   used to generate an ASP Down Acknowledgement.

   M-ASP-ACTIVE

   The M-ASP-UP primitive can be used by Layer Management to send a ASP
   Active message for the Application Server Process.  It can also be
   used to generate an ASP Active Acknowledgement.

   M-ASP-INACTIVE

   The M-ASP-UP primitive can be used by Layer Management to send a ASP
   Inactive message for the Application Server Process.  It can also be
   used to generate an ASP Inactive Acknowledgement.

   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.









Morneault, et al.           Standards Track                    [Page 11]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


1.5 Functions Implemented by the IUA Layer

1.5.1 Mapping

   The IUA layer MUST maintain a map of the Interface Identifier to a
   physical interface on the Signaling Gateway.  A physical interface
   would be a T1 line, E1 line, etc., and could include the TDM
   timeslot. In addition, for a given interface the SG MUST be able to
   identify the associated signaling channel.  IUA layers on both SG and
   MGC MAY maintain the status of TEIs and SAPIs.

   The SG 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
   failover of one ASP to another.  Therefore, the SG MUST maintain the
   states of AS/ASP and reference them during the routing of an messages
   to an AS/ASP.

   One example of the logical view of relationship between D channel,
   Interface Identifier, AS and ASP in the SG is shown below:

          /---------------------------------------------------+
         /   /------------------------------------------------|--+
        /   /                                                 v  |
       /   /    +----+             act+-----+    +-------+ -+--+-|+--+-
D chan1-------->|IID |-+          +-->| ASP |--->| Assoc |       v
         /      +----+ |  +----+  |   +-----+    +-------+ -+--+--+--+-
        /              +->| AS |--+                        Streams
       /        +----+ |  +----+   stb+-----+
D chan2-------->|IID |-+              | ASP |
                +----+                +-----+

   where IID = Interface Identifier

   Note that an ASP can be in more than one AS.

1.5.2 Status of ASPs

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






Morneault, et al.           Standards Track                    [Page 12]

RFC 3057            ISDN Q.921-User Adaptation Layer       February 2001


   At a SG, an Application Server list MAY contain active and inactive
   ASPs to support ASP load-sharing and fail-over procedures.  When, for
   example, both a primary and a back-up ASP are available, IUA 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 SG to reflect the active Application Server
   Process(es).

   Also the IUA 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.3 SCTP Stream Management