tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3868

Proposed STD
Pages: 131
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIGTRAN

Signalling Connection Control Part User Adaptation Layer (SUA)

Part 1 of 5, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                   J. Loughney, Ed.
Request for Comments: 3868                                         Nokia
Category: Standards Track                                  G. Sidebottom
                                                   Signatus Technologies
                                                                L. Coene
                                                              G. Verwimp
                                                            Siemens n.v.
                                                               J. Keller
                                                                 Tekelec
                                                             B. Bidulock
                                                     OpenSS7 Corporation
                                                            October 2004


    Signalling Connection Control Part User Adaptation Layer (SUA)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines a protocol for the transport of any Signalling
   Connection Control Part-User signalling over IP using the Stream
   Control Transmission Protocol.  The protocol is designed to be
   modular and symmetric, to allow it to work in diverse architectures,
   such as a Signalling Gateway to IP Signalling Endpoint architecture
   as well as a peer-to-peer IP Signalling Endpoint architecture.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Abbreviations and Terminology. . . . . . . . . . . . . .  4
       1.3.  Signalling Transport Architecture. . . . . . . . . . . .  6
       1.4.  Services Provided by the SUA Layer . . . . . . . . . . .  9
       1.5.  Internal Functions Provided in the SUA Layer . . . . . . 11
       1.6.  Definition of SUA Boundaries . . . . . . . . . . . . . . 14
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 19
   3.  Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 19
       3.1.  Common Message Header. . . . . . . . . . . . . . . . . . 20
       3.2.  SUA Connectionless Messages. . . . . . . . . . . . . . . 24
       3.3.  Connection Oriented Messages . . . . . . . . . . . . . . 27
       3.4.  Signalling Network Management (SNM) Messages . . . . . . 42
       3.5.  Application Server Process State Maintenance Messages. . 49
       3.6.  ASP Traffic Maintenance Messages . . . . . . . . . . . . 53
       3.7.  SUA Management Messages. . . . . . . . . . . . . . . . . 56
       3.8.  Routing Key Management (RKM) Messages. . . . . . . . . . 58
       3.9.  Common Parameters. . . . . . . . . . . . . . . . . . . . 61
       3.10. SUA-Specific parameters. . . . . . . . . . . . . . . . . 74
   4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 92
       4.1.  Procedures to Support the SUA-User Layer . . . . . . . . 92
       4.2.  Receipt of Primitives from the Layer Management. . . . . 93
       4.3.  AS and ASP State Maintenance . . . . . . . . . . . . . . 95
       4.4.  Routing Key Management Procedures. . . . . . . . . . . .109
       4.5.  Availability and/or Congestion Status of SS7
             Destination Support101 . . . . . . . . . . . . . . . . .112
       4.6.  MTP3 Restart . . . . . . . . . . . . . . . . . . . . . .115
       4.7.  SCCP - SUA Interworking at the SG. . . . . . . . . . . .115
   5.  Examples of SUA Procedures . . . . . . . . . . . . . . . . . .117
       5.1.  SG Architecture. . . . . . . . . . . . . . . . . . . . .117
       5.2   IPSP Examples. . . . . . . . . . . . . . . . . . . . . .119
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . .121
   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .121
       7.1.  SCTP Payload Protocol ID . . . . . . . . . . . . . . . .121
       7.2.  Port Number. . . . . . . . . . . . . . . . . . . . . . .121
       7.3.  Protocol Extensions. . . . . . . . . . . . . . . . . . .121
   8.  Timer Values . . . . . . . . . . . . . . . . . . . . . . . . .123
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .123
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .123
       10.1. Normative References . . . . . . . . . . . . . . . . . .123
       10.2. Informative References . . . . . . . . . . . . . . . . .124

Top      ToC       Page 3 
   Appendix A.  Signalling Network Architecture . . . . . . . . . . .125
       A.1.  Generalized Peer-to-Peer Network Architecture. . . . . .125
       A.2.  Signalling Gateway Network Architecture. . . . . . . . .126
       A.3.  Signalling Gateway Message Distribution
             Recommendations. . . . . . . . . . . . . . . . . . . . .128
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .129
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .131

1.  Introduction

   There is ongoing integration of switched circuit networks and IP
   networks.  Network service providers are designing IP-based
   signalling architectures that need support for SS7 and SS7-like
   signalling protocols.  IP provides an effective way to transport user
   data and for operators to expand their networks and build new
   services.  In these networks, there is need for interworking between
   the SS7 and IP domains [2719].

   This document defines a protocol for the transport SS7 SCCP-User
   protocols [ANSI SCCP] [ITU SCCP], such as TCAP and RANAP, over IP
   using the Stream Control Transmission Protocol (SCTP) [2960].

1.1.  Scope

   This document details the delivery of SCCP-user messages (MAP & CAP
   over TCAP [ANSI TCAP] [ITU TCAP], RANAP [RANAP], etc.) messages over
   IP between two signalling endpoints.  Consideration is given for the
   transport from a signalling gateway to an IP signalling node (such as
   an IP-resident Database) as described in the Framework Architecture
   for Signalling Transport [2719].  This protocol can also support
   transport of SCCP-user messages between two endpoints wholly
   contained within an IP network.

   The delivery mechanism addresses the following criteria:

   *  Support for transfer of SCCP-User Part messages
   *  Support for SCCP connectionless service.
   *  Support for SCCP connection oriented service.
   *  Support for the operation of SCCP-User protocol peers.
   *  Support for the management of SCTP transport associations between
      signalling gateways and IP-based signalling nodes.
   *  Support for distributed IP-based signalling nodes.
   *  Support for the asynchronous reporting of status changes to
      management functions.

Top      ToC       Page 4 
1.2.  Abbreviations and Terminology

1.2.1.  Abbreviations

   CAP - CAMEL Application Protocol.

   GTT - Global Title Translation.

   MAP - Mobile Application Protocol.

   PC - Signalling System no. 7 Point Code.

   RANAP - Radio Access Network Application Protocol.

   SCTP - Stream Control Transmission Protocol.

   SS7 - Signalling System no. 7.

   TCAP - Transaction Capabilities Application Protocol.

1.2.2.  Terminology

   Signalling Gateway (SG) - Network element that terminates switched
   circuit networks and transports SCCP-User signalling over IP to an IP
   signalling endpoint.  A Signalling Gateway could be modeled as one or
   more Signalling Gateway Processes, which are located at the border of
   the SS7 and IP networks.  Where an SG contains more than one SGP, the
   SG is a logical entity and the contained SGPs are assumed to be
   coordinated into a single management view to the SS7 network and to
   the supported Application Servers.

   Application Server (AS) - A logical entity serving a specific Routing
   Key.  An example of an Application Server is a virtual IP database
   element handling all requests for an SCCP-user.  The AS contains a
   set of one or more unique Application Server Processes, of which one
   or more is normally actively processing traffic.

   Application Server Process (ASP) - An Application Server Process
   serves as an active or backup process of an Application Server (e.g.,
   part of a distributed signalling node or database element). Examples
   of ASPs are MGCs, IP SCPs, or IP-based HLRs.  An ASP contains an SCTP
   endpoint and may be configured to process traffic within more than
   one Application Server.

   IP Server Process (IPSP) - A process instance of an IP-based
   application.  An IPSP is essentially the same as an ASP, except that
   it uses SUA in a peer-to-peer fashion.  Conceptually, an IPSP does
   not use the services of a Signalling Gateway.

Top      ToC       Page 5 
   Signalling Gateway Process (SGP) - A process instance of a Signalling
   Gateway.  It serves as an active, load-sharing or broadcast process
   of a Signalling Gateway.

   Signalling Process - A process instance that uses SUA to communicate
   with other signalling process.  An ASP, a SGP and an IPSP are all
   signalling processes.

   Association - An association refers to an SCTP association.  The
   association provides the transport for the delivery of SCCP-User
   protocol data units and SUA layer peer messages.

   Routing Key - The Routing Key describes a set of SS7 parameters
   and/or parameter ranges that uniquely defines the range of signalling
   traffic configured to be handled by a particular Application Server.
   An example would be where a Routing Key consists of a particular SS7
   SCCP SSN plus an identifier to uniquely mark the network that the SSN
   belongs to, for which all traffic would be directed to a particular
   Application Server.  Routing Keys are mutually exclusive in the sense
   that a received SS7 signalling message cannot be directed to more
   than one Routing Key.  Routing Keys can be provisioned, for example,
   by a MIB or registered using SUA's dynamic registration procedures.
   Routing keys MUST NOT span multiple network appearances.

   Routing Context - An Application Server Process may be configured to
   process traffic within more than one Application Server.  In this
   case, the Routing Context parameter is exchanged between the SGP and
   the ASP (or between two ASPs), identifying the relevant Application
   Server.  From the perspective of an SGP/ASP, the Routing Context
   uniquely identifies the range of traffic associated with a particular
   Application Server, which the ASP is configured to receive.  There is
   a 1:1 relationship between a Routing Context value and a Routing Key
   within an AS.  Therefore the Routing Context can be viewed as an
   index into an AS Table containing the AS Routing Keys.

   Address Mapping Function (AMF) - The AMF is an implementation
   dependent function that is responsible for resolving the address
   presented in the incoming SCCP/SUA message to correct SCTP
   association for the desired endpoint.  The AMF MAY use routing
   context / routing key information as selection criteria for the
   appropriate SCTP association.

   Fail-over - The capability to reroute signalling traffic as required
   to an alternate Application Server Process, or group of ASPs, within
   an Application Server in the event of failure or unavailability of a
   currently used Application Server Process. Fail-over may apply upon
   the return to service of a previously unavailable Application Server
   Process.

Top      ToC       Page 6 
   Host - The computing platform that the SGP or ASP process is running
   on.

   Layer Management - Layer Management is a nodal function that handles
   the inputs and outputs between the SUA layer and a local management
   entity.

   Network Appearance - The Network Appearance is an SUA local reference
   (typically an integer) shared by SG and AS that together with a
   Signalling Point Code uniquely identifies an SS7 node by indicating
   the specific SS7 network it belongs to.

   Network Byte Order - Most significant byte first, a.k.a. Big Endian.

   Stream - A stream refers to an SCTP stream; a unidirectional logical
   channel established from one SCTP endpoint to another associated SCTP
   endpoint, within which all user messages are delivered sequenced
   except for those submitted to the unordered delivery service.

   Transport address - an address that serves as a source or destination
   for the unreliable packet transport service used by SCTP.  In IP
   networks, a transport address is defined by the combination of an IP
   address and an SCTP port number.  Note, only one SCTP port may be
   defined for each endpoint, but each SCTP endpoint may have multiple
   IP addresses.

1.3.  Signalling Transport Architecture

   The framework architecture that has been defined for switched circuit
   networks signalling transport over IP [2719] uses multiple
   components, including an IP transport protocol, a signalling common
   transport protocol and an adaptation module to support the services
   expected by a particular switched circuit networks signalling
   protocol from its underlying protocol layer.

   In general terms, the SUA architecture can be modeled as a peer-to-
   peer architecture.  The first section considers the SS7 to IP
   interworking architectures for connectionless and connection-oriented
   transport.  For this case, it is assumed that the ASP initiates the
   establishment of the SCTP association with SG.

1.3.1.  Protocol Architecture for Connectionless Transport

   In this architecture, the SCCP and SUA layers interface in the SG.
   Interworking between the SCCP and SUA layers is needed to provide for
   the transfer of the user messages as well as the management messages.

Top      ToC       Page 7 
      ********   SS7   ***************   IP   ********
      * SEP  *---------*             *--------*      *
      *  or  *         *      SG     *        * ASP  *
      * STP  *         *             *        *      *
      ********         ***************        ********

      +------+                                +------+
      | SUAP |                                | SUAP |
      +------+         +------+------+        +------+
      | SCCP |         | SCCP | SUA  |        | SUA  |
      +------+         +------+------+        +------+
      | MTP3 |         | MTP3 |      |        |      |
      +------+         +------+ SCTP |        | SCTP |
      | MTP2 |         | MTP2 |      |        |      |
      +------+         +------+------+        +------+
      |  L1  |         |  L1  |  IP  |        |  IP  |
      +------+         +------+------+        +------+
          |               |         |            |
          +---------------+         +------------+

        SUAP - SCCP/SUA User Protocol (TCAP, for example)
        STP  - SS7 Signalling Transfer Point

   See Appendix A.3.1 for operation recommendations.

1.3.1.1.  SG as endpoint

   In this case, the connectionless SCCP messages are routed on point
   code (PC) and subsystem number (SSN).  The subsystem identified by
   SSN and Routing Context is regarded as local to the SG.  This means
   from SS7 point of view, the SCCP-user is located at the SG.

1.3.1.2.  Signalling Gateway as relay-point

   A Global Title translation is executed at the signalling gateway,
   before the destination of the message can be determined.  The actual
   location of the SCCP-user is irrelevant to the SS7 network.  GT
   Translation yields an "SCCP entity set", from which an Application
   Server can be derived.  Selection of the Application Server is based
   on the SCCP called party address (and possibly other SS7 parameters
   depending on the implementation).

Top      ToC       Page 8 
1.3.2.  Protocol Architecture for Connection-Oriented Transport

   In this architecture, the SCCP and SUA layers share an interface in
   the signalling gateway process to associate the two connection
   sections needed for the connection-oriented data transfer between SEP
   and ASP.  Both connection sections are setup when routing the Connect
   Request messages from the signalling end point via signalling gateway
   process to ASP and visa versa.  The routing of the Connect Request
   message is performed in the same way as described in 1.3.1.

      ********   SS7   ***************   IP   ********
      * SEP/ *---------*      SG     *--------* ASP  *
      * STP  *         *             *        *      *
      ********         ***************        ********

      +------+                                +------+
      | SUAP |                                | SUAP |
      +------+         +------+------+        +------+
      | SCCP |         | SCCP | SUA  |        | SUA  |
      +------+         +------+------+        +------+
      | MTP3 |         | MTP3 |      |        |      |
      +------|         +------+ SCTP |        | SCTP |
      | MTP2 |         | MTP2 |      |        |      |
      +------+         +------+------+        +------+
      |  L1  |         |  L1  |  IP  |        |  IP  |
      +------+         +------+------+        +------+
          |               |         |            |
          +---------------+         +------------+

        SUAP - SCCP/SUA Application Protocol (e.g., - RANAP/RNSAP)
        STP  - SS7 Signalling Transfer Point

   See Appendix A.3.2 for operation recommendations.

1.3.3.  All IP Architecture

   This architecture can be used to carry a protocol that uses the
   transport services of SCCP within an IP network.  This allows
   flexibility in developing networks, especially when interaction
   between legacy signalling is not needed.  The architecture removes
   the need for signalling gateway functionality.

Top      ToC       Page 9 
      ********   IP   ********
      * IPSP *--------* IPSP *
      ********        ********

      +------+        +------+
      | SUAP |        | SUAP |
      +------+        +------+
      | SUA  |        | SUA  |
      +------+        +------+
      | SCTP |        | SCTP |
      +------+        +------+
      |  IP  |        |  IP  |
      +------+        +------+
         |                |
         +----------------+

      SUAP - SCCP/SUA Application Protocol (e.g., - RANAP/RNSAP)

1.3.4.  ASP Fail-over Model and Terminology

   The SUA protocol supports ASP fail-over functions to support a high
   availability of transaction processing capability.

   An Application Server can be considered as a list of all ASPs
   configured/registered to handle SCCP-user messages within a certain
   range of routing information, known as a Routing Key.  One or more
   ASPs in the list may normally be active to handle traffic, while
   others may be inactive but available in the event of failure or
   unavailability of the active ASP(s).

   For operation recommendations, see Appendix A.

1.4.  Services Provided by the SUA Layer

1.4.1.  Support for the transport of SCCP-User Messages

   The SUA supports the transfer of SCCP-user messages.  The SUA layer
   at the signalling gateway and at the ASP support the seamless
   transport of user messages between the signalling gateway and the
   ASP.

1.4.2.  SCCP Protocol Class Support

   Depending upon the SCCP-users supported, the SUA supports the 4
   possible SCCP protocol classes transparently.  The SCCP protocol
   classes are defined as follows:

Top      ToC       Page 10 
   *  Protocol class 0 provides unordered transfer of SCCP-user messages
      in a connectionless manner.

   *  Protocol class 1 allows the SCCP-user to select the sequenced
      delivery of SCCP-user messages in a connectionless manner.

   *  Protocol class 2 allows the bidirectional transfer of SCCP-user
      messages by setting up a temporary or permanent signalling
      connection.

   *  Protocol class 3 allows the features of protocol class 2 with the
      inclusion of flow control.  Detection of message loss or mis-
      sequencing is included.

   Protocol classes 0 and 1 make up the SCCP connectionless service.
   Protocol classes 2 and 3 make up the SCCP connection-oriented
   service.

1.4.3.  Native Management Functions

   The SUA layer provides the capability to indicate errors associated
   with the SUA-protocol messages and to provide notification to local
   management and the remote peer as is necessary.

1.4.4.  Interworking with SCCP Network Management Functions

   SUA uses the existing ASP management messages for ASP status
   handling.  The interworking with SCCP management messages consists of
   DUNA, DAVA, DAUD, DRST, DUPU or SCON messages (defined in section 3)
   on receipt of SSP, SSA, SST or SSC (defined by SCCP) to the
   appropriate ASPs.  See also chapter 1.4.5.  The primitives below are
   sent between the SCCP and SUA management functions in the SG to
   trigger events in the IP and SS7 domain.

   Generic   |Specific   |
   Name      |Name       |ANSI/ITU Reference
   ----------+-----------+---------------------------------------------
   N-State   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-PCstate |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 1/Q.711)
             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-Coord   |Request    |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
             |Response   |
             |Confirm    |

Top      ToC       Page 11 
1.4.5.  Support for the management between the SGP and ASP.

   The SUA layer provides interworking with SCCP management functions at
   the SG for operation between the switched circuit networks and the IP
   network.  It should:

   *  Provide an indication to the SCCP-user at an ASP that a SS7
      endpoint/peer is unreachable.
   *  Provide an indication to the SCCP-user at an ASP that a SS7
      endpoint/peer is reachable.
   *  Provide congestion indication to SCCP-user at an ASP.
   *  Provide the initiation of an audit of SS7 endpoints at the SG.

1.4.6.  Relay function

   For network scalability purposes, the SUA may be enhanced with a
   relay functionality to determine the next hop SCTP association toward
   the destination SUA endpoint.

   The determination of the next hop may be based on Global Title
   information (e.g., E.164 number), in analogy with SCCP GTT in SS7
   networks, modeled in [ITU-T Q.714].  It may also be based on Hostname
   information, IP address or pointcode contained in the called party
   address.

   This allows for greater scalability, reliability and flexibility in
   wide-scale deployments of SUA.  The usage of a relay function is a
   deployment decision.

1.5.  Internal Functions Provided in the SUA Layer

   To perform its addressing and relaying capabilities, the SUA makes
   use of an Address Mapping Function (AMF).  This function is
   considered part of SUA, but the way it is realized is left
   implementation / deployment dependent (local tables, DNS [3761],
   LDAP, etc.)

   The AMF is invoked when a message is received at the incoming
   interface.  The AMF is responsible for resolving the address
   presented in the incoming SCCP/SUA message to SCTP associations to
   destinations within the IP network.  The AMF will select the
   appropriate SCTP association based upon routing context / routing key
   information available.  The destination might be the end SUA node or
   a SUA relay node.  The Routing Keys reference an Application Server,
   which will have one or more ASPs processing traffic for the AS.  The
   availability and status of the ASPs is handled by SUA ASP management
   messages.

Top      ToC       Page 12 
   Possible SS7 address/routing information that comprise a Routing Key
   entry includes, for example, OPC, DPC, SIO found in the MTP3 routing
   label, SCCP subsystem number, or Transaction ID.  IP addresses and
   hostnames can also be used as Routing Key Information.

   It is expected that the routing keys be provisioned via a MIB,
   dynamic registration or external process, such as a database.

1.5.1.  Address Mapping at the SG

   Normally, one or more ASPs are active in the AS (i.e., currently
   processing traffic) but in certain failure and transition cases it is
   possible that there may not be an active ASP available.  The SGP will
   buffer the message destined for this AS for a time T(r) or until an
   ASP becomes available.  When no ASP becomes available before expiry
   of T(r), the SGP will flush the buffered messages and initiate the
   appropriate return or refusal procedures.

   If there is no address mapping match for an incoming message, a
   default treatment MAY be specified.  Possible solutions are to
   provide a default Application Server to direct all unallocated
   traffic to a (set of) default ASP(s), or to drop the messages and
   provide a notification to management.  The treatment of unallocated
   traffic is implementation dependent.

1.5.2.  Address Mapping at the ASP

   To direct messages to the SS7 network, the ASP MAY perform an address
   mapping to choose the proper SGP for a given message.  This is
   accomplished by observing the Destination Point Code and other
   elements of the outgoing message, SS7 network status, SGP
   availability, and Routing Context configuration tables.

   A Signalling Gateway may be composed of one or more SGPs.  There is,
   however, no SUA messaging to manage the status of an SGP.  Whenever
   an SCTP association to an SGP exists, it is assumed to be available.
   Also, every SGP of one SG communicating with one ASP regarding one AS
   provides identical SS7 connectivity to this ASP.

   An ASP routes responses to the SGP that it received messages from;
   within the routing context which it is currently active and receiving
   traffic.

1.5.3.  Address Mapping Function at a Relay Node

   The relay function is invoked when:

   -  Routing is on Global Title

Top      ToC       Page 13 
   -  Routing is on Hostname
   -  Routing is on SSN and PC or SSN and IP Address and the address
      presented is not the one of the relay node

   Translation/resolution of the above address information yields one of
   the following:

   -  Route on SSN: SCTP association ID toward the destination node, SSN
      and optionally Routing Context and/or IP address.
   -  Route on GT: SCTP association ID toward next relay node, (new) GT
      and optionally SSN and/or Routing Context.
   -  Routing on Hostname: SCTP association ID toward next relay node,
      (new) Hostname and optionally SSN and/or Routing Context.
   -  A local SUA-user (combined relay/end node)

   To prevent looping, an SS7 hop counter is used.  The originating end
   node (be it an SS7 or an IP node) sets the value of the SS7 hop
   counter to the maximum value (15 or less).  Each time the relay
   function is invoked within an intermediate (relay) node, the SS7 hop
   counter is decremented.  When the value reaches zero, the return or
   refusal procedures are invoked with reason "Hop counter violation".

1.5.4.  SCTP Stream Mapping

   The SUA supports SCTP streams.  Signalling Gateway SG and Application
   Servers need to maintain a list of SCTP and SUA-users for mapping
   purposes.  SCCP-users requiring sequenced message transfer need to be
   sent over a stream with sequenced delivery.

   SUA uses stream 0 for SUA management messages.  It is OPTIONAL that
   sequenced delivery be used to preserve the order of management
   message delivery.

   Stream selection based on protocol class:

   -  Protocol class 0: SUA MAY select unordered delivery.  The stream
      selected is based on traffic information available to the SGP or
      ASP.

   -  Protocol class 1: SUA MUST select ordered delivery.  The stream
      selected is based upon the sequence parameter given by the upper
      layer over the primitive interface and other traffic information
      available to the SGP or ASP

   -  Protocol classes 2 and 3: SUA MUST select ordered delivery. The
      stream selected is based upon the source local reference of the
      connection and other traffic information available to the SGP or
      ASP.

Top      ToC       Page 14 
1.5.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.5.6.  Congestion Management

   The SUA 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 SUA layer indicates congestion to local SCCP-
   Users by means of an appropriate SCCP primitive (e.g., N-INFORM, N-
   NOTICE), as per current SCCP procedures, to invoke appropriate upper
   layer responses.  When an SG determines that the transport of SS7
   messages is encountering congestion, the SG MAY trigger SS7 SCCP
   Congestion messages to originating SS7 nodes, per the congestion
   procedures of the relevant SCCP standard.  The triggering of SS7 SCCP
   Management messages from an SG is an implementation-dependent
   function.

   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.  When an SG receives a congestion
   message (SCON) from an ASP, and the SG determines that an endpoint is
   now encountering congestion, it MAY trigger congestion procedures of
   the relevant SCCP standard.

1.6.  Definition of SUA Boundaries

1.6.1.  Definition of the upper boundary

   The following primitives are supported between the SUA and an SCCP-
   user (a reference to ITU and ANSI sections where these primitives and
   corresponding parameters are described, is also given):

   Generic     |Specific  |
   Name        |Name      |ANSI/ITU Reference
   ------------+----------+-------------------------------------------
   N-CONNECT   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-DATA      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)

Top      ToC       Page 15 
   ------------+----------+-------------------------------------------
   N-EXPEDITED |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)
   DATA        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
   ------------+----------+-------------------------------------------
   N-RESET     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-DISCONNECT|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
   ------------+----------+-------------------------------------------
   N-INFORM    |Request   |ITU-Q.711   Chap 6.1.1.3.2 (Tab 8/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-UNITDATA  |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 12/Q.711)
               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-NOTICE    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 13/Q.711)
               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
   ------------+----------+--------------------------------------------
   N-STATE     |Request   |ITU-Q.711   Chap 6.3.2.3.2 (Tab 16/Q.711)
               |Indication|ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ------------+----------+--------------------------------------------
   N-PCSTATE   |Indication|ITU-Q.711   Chap 6.3.2.3.3 (Tab 17/Q.711)
               |          |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
   ------------+----------+--------------------------------------------
   N-COORD     |Request   |ITU-Q.711   Chap 6.3.2.3.1 (Tab 15/Q.711)
               |Indication|ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
               |Response  |
               |Confirm   |

1.6.2.  Definition of the lower boundary

   The upper layer primitives provided by the SCTP are provided in
   [SCTP].

1.6.3.  Definition of the Boundary between SUA and Layer Management

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

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

Top      ToC       Page 16 
   M-SCTP_ESTABLISH indication
   Direction: SUA -> LM
   Purpose:  SUA informs LM that a remote ASP has established an SCTP
             association.

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

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

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

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

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

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

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

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

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

Top      ToC       Page 17 
   M-AS_STATUS request
   Direction: LM -> SUA
   Purpose:  LM requests SUA to report the status of an AS.

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

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

   M-ERROR indication
   Direction: SUA -> LM
   Purpose:  SUA 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 -> SUA
   Purpose:  LM requests ASP to start its operation and send an ASP Up
             message to its peer.

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

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

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

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

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

Top      ToC       Page 18 
   M-ASP_ACTIVE request
   Direction: LM -> SUA
   Purpose:  LM requests ASP to send an ASP Active message to its peer.

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

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

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

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

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

   M-AS_ACTIVE indication
   Direction: SUA -> LM
   Purpose:  SUA reports that an AS has moved to the AS-ACTIVE state.

   M-AS_INACTIVE indication
   Direction: SUA -> LM
   Purpose: SUA reports that an AS has moved to the AS-INACTIVE state.

   M-AS_DOWN indication
   Direction: SUA -> LM
   Purpose: SUA reports that an AS has moved to the AS-DOWN state.

Top      ToC       Page 19 
   If the SUA layer supports dynamic registration of Routing Key, the
   layer MAY support the following additional primitives:

   M-RK_REG request
   Direction: LM -> SUA
   Purpose:  LM requests ASP to register RK(s) with its peer by sending
             REG REQ message.

   M-RK_REG confirm
   Direction: SUA -> LM
   Purpose:  ASP reports that it has received REG RSP message with
             registration status as successful from its peer.

   M-RK_REG indication
   Direction: SUA -> LM
   Purpose:  SUA informs LM that it has successfully processed an
             incoming REG REQ message.

   M-RK_DEREG request
   Direction: LM -> SUA
   Purpose:  LM requests ASP to deregister RK(s) with its peer by
             sending DEREG REQ message.

   M-RK_DEREG confirm
   Direction: SUA -> LM
   Purpose:  ASP reports that it has received DEREG RESP message with
             deregistration status as successful from its peer.

   M-RK_DEREG indication
   Direction: SUA -> LM
   Purpose:  SUA informs LM that it has successfully processed an
             incoming DEREG REQ from its peer.

2.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   BCP 14, RFC 2119 [2119].



(page 19 continued on part 2)

Next RFC Part