Network Working Group G. Sidebottom, L. Ong, Guy Mousseau INTERNET-DRAFT Nortel Networks Ian Rytina Ericsson Hanns-Juergen Schwarzbauer Siemens Ken Morneault Cisco Mallesh Kalla Telcordia Expires in six months 15 February 2000 SS7 MTP3-User Adaptation Layer (M3UA) Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft defines a protocol for the transport of any SS7 MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the Simple Control Transport Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP- resident Database. It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 1] Internet Draft MTP3-User Adaptation Layer Feb 2000 TABLE OF CONTENTS 1. Introduction..............................................3 2. Protocol Elements........................................11 3. Procedures...............................................21 4. Examples.................................................26 5. Security.................................................27 6. Acknowledgements.........................................27 7. References...............................................27 8. Author's Addresses.......................................28 Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 2] Internet Draft MTP3-User Adaptation Layer Feb 2000 1. Introduction 1.1 Scope There is a need for SCN signaling protocol delivery from an SS7 Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP- resident Database as described in the Framework Architecture for Signalling Transport [1]. The delivery mechanism should meet the following criteria: * Support for transfer of all SS7 MTP3-User Part messages (e.g., ISUP, SCCP, TUP, etc.) * Support for the seamless operation of MTP3-User protocol peers * Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases * Support for MGC or IP-resident Database failover and loadsharing * Support for the asynchronous reporting of status changes to management In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols and deliver ISUP, SCCP and/or any other MTP3-User protocol messages over SCTP transport associations to MTP3-User peers in MGCs or IP- resident Databases. 1.2 Terminology Application Node (AN) - A physical node in an IP network (i.e., an MGCU or Database node), with one or more unique IP network addresses. An AN supports one or more SCTP end-points and one or more Application Server Processes. Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a virtual switch element handling all call processing for a unique range of PSTN trunks, identified by an SS7 DPC/OPC/CIC_range. Practically speaking, an AS is modeled at the SG as an ordered list of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or standby process of an Application Server (e.g., part of a distributed virtual switch or database element). Association - An association refers to an SCTP association. The association provides the transport for the delivery of MTP3-User protocol data units and M3UA adaptation layer peer messages. Fail-over - The capability to re-route signaling traffic as required to an alternate Application Server Process, or group of ASPs, within an Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 3] Internet Draft MTP3-User Adaptation Layer Feb 2000 Application Server in the event of failure or unavailability of a currently used Application Server Process. Fail-back may apply upon the return to service of a previously unavailable Application Server Process. IP Database - The IP-resident analogue of a PSTN Service Control Point (SCP) or wireless Home Location Register (HLR). MTP3 Management Cluster (MMC) - A group of one or more Application Servers represented to the SS7 network under the same SS7 Destination Point Code. MMCs are used to sum the availability/congestion status of an SS7 destination that is distributed in the IP domain, for the purpose of supporting MTP Level 3 management procedures. MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Network Appearance - The Network Appearance identifies the SS7 network context for the purposes of logically separating the signaling traffic between the SG and the Application Server Processes over common SCTP Associations. An example is where an SG is logically partitioned to appear as an element in four separate SS7 national networks. A Network Appearance uniquely defines the SS7 Destination Point Code, Network Indicator and MTP3 protocol type/variant/version used within each network. An SS7 route-set or link-set at an SG can appear in only one network appearance. Network Byte Order: Most significant byte first, a.k.a Big Endian. Routing Context - An Application Server Process may be configured to process traffic within more than one Application Server. From the perspective of an ASP, a Routing Context defines a range of signaling traffic that the ASP is currently configured to receive from the SG. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signaling traffic, identified by separate SS7 DPC/OPC/CIC_ranges. Stream - A stream refers to an SCTP stream. 1.3 Signaling Transport Architecture 1.3.1 Protocol Architecture. The framework architecture that has been defined for SCN signaling transport over IP [1] uses multiple components, including a signaling common transport protocol and an adaptation module to support the services expected by a particular SCN signaling protocol from its underlying protocol layer. Within the framework architecture, this document defines an MTP3-User Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 4] Internet Draft MTP3-User Adaptation Layer Feb 2000 adaptation module that is suitable for the transport of SS7 ISDN User Part (ISUP) [2,3,4] and Signalling Connection Control Part (SCCP) [5,6,7] messages but could be equally used to transport other SS7 MTP3- User Part messages such as, for example, the Telephone User Part (TUP) [8]. TCAP [9,10,11] or RANAP [12] messages are transported transparently by the M3UA as SCCP payload, as they are SCCP-User protocols. The M3UA uses the services of the Simple Common Transport protocol [13] as the underlying reliable signaling common transport protocol. In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling is transmitted and received from the PSTN over a standard SS7 network interface, using the SS7 Message Transfer Part (MTP) [14,15,16] to provide reliable transport of the ISUP/SCCP signaling messages to and from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). The SG then provides a functional inter-working of transport functions with the IP transport, in order to transfer the ISUP/SCCP signaling messages to and from an Application Server Process where the peer ISUP/SCCP protocol layer exists. The use of standard MTP Level 2 signaling links in the SS7 network interface is not the only possibility. ATM-based High Speed Links could also be used, using the services of the Signaling ATM Adaptation Layer (SAAL) [17,18]. For that matter, it is possible that IP-based links could be present, using the services of the MTP2-User Adaptation Layer (M2UA) [19]. Also note that STPs may be present in the SS7 path between the SS7 SEP and the SG. Where ATM-base High Speed Links are used in the SS7 network, it is possible for the SG to use the services of the MTP-3b [20] for reliable transport to and from an SS7 SEP or STP. The maximum Service Data Unit (SDU) supported by the MTP-3b is 4096 octets compared to the 272 octet maximum of the MTP. However, for MTP3-Users to take advantage of the larger SDU between MTP3-User peers, network architects should ensure that MTP3-b is used end-to-end between the SG and the SS7-resident peer. Three example cases are shown below: 1.3.1.1 Example 1: ISUP transport Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 5] Internet Draft MTP3-User Adaptation Layer Feb 2000 ******** SS7 ***************** IP ******** * SEP *---------* SG *--------* ASP * ******** ***************** ******** +------+ +------+ | ISUP | | ISUP | +------+ +------+-+------+ +------+ | MTP3 | | MTP3 | | M3UA | | M3UA | +------| +------+ +------+ +------+ | MTP2 | | MTP2 | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | L1 | | L1 | | UDP | | UDP | +------+ +------+ +------+ +------+ |_______________| |______________| SEP - SS7 Signaling End Point SCTP - Simple Control Transport Protocol Within the SG, MTP-TRANSFER indication primitives received from the MTP Level 3 upper layer interface are sent to the local M3UA-resident network address translation and mapping function for ongoing routing to the final IP destination. MTP-TRANSFER primitives received from the local M3UA network address translation and mapping function are sent to the MTP Level 3 upper layer interface as MTP-TRANSFER request primitives for on-going MTP Level 3 routing to an SS7 SEP. For internal SG modelling purposes, this may be accomplished with the use of an implementation-dependent nodal inter-working function within the SG that serves as a local user of the MTP3 and M3UA. This nodal inter-working function has no visible peer protocol with either the ASP or SEP. 1.3.1.2 Example 2: SCCP transport where an SCCP function at the SG is invoked: ******** SS7 ***************** IP ******** * SEP *---------* *--------* * * or * * SG * * ASP * * STP * * * * * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP | | SCCP | | SCCP | +------+ +------+-+------+ +------+ | MTP3 | | MTP3 | | M3UA | | M3UA | +------| +------+ +------+ +------+ | MTP2 | | MTP2 | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | L1 | | L1 | | UDP | | UDP | +------+ +------+ +------+ +------+ |_______________| |______________| STP - SS7 Signaling Transfer Point Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 6] Internet Draft MTP3-User Adaptation Layer Feb 2000 In this example, the SG contains an instance of the SS7 SCCP protocol layer that may, for example, perform the SCCP Global Title Translation (GTT) function for messages logically addressed to the SG SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN address result of an SCCP peer located in the IP domain, the resulting MTP-TRANSFER request primitive is sent to the local M3UA-resident network address translation and mapping function for ongoing routing to the final IP destination. Similarly, the SCCP instance in an SG can perform the SCCP GTT service for messages logically addressed to it from SCCP peers in the IP domain. In this case, MTP-TRANSFER messages are sent from the local M3UA-resident network address translation and mapping function to the SCCP for GTT. If the result of the GTT yields the address of an SCCP peer in the SS7 network then the resulting MTP-TRANSFER request is given to the MTP3 for delivery to an SS7-resident node. It is possible that the above SCCP GTT at the SG could yield the address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER primitive would be sent back to the M3UA for delivery to an IP destination. For internal SG modelling purposes, this may be accomplished with the use of an implementation-dependent nodal inter-working function within the SG that effectively sits below the SCCP and routes MTP-TRANSFER messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or DPC/SSN address information. This nodal inter-working function has no visible peer protocol with either the ASP or SEP. Note that the services and interface provided by M3UA are the same as in Example 1 and the functions taking place in the SCCP entity are transparent to M3UA. The SCCP protocol functions are not reproduced in the M3UA protocol. 1.3.1.3 Example 3 - Seamless Handling of MTP3 Management ******** SS7 ***************** IP ******** * SEP *---------* *--------* * * or * * SG * * ASP * * STP * * * * * ******** ***************** ******** +------+ +------+-+------+ +------+ | MTP3 | | MTP3 | | M3UA | | M3UA | +------| +------+ +------+ +------+ | MTP2 | | MTP2 | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | L1 | | L1 | | UDP | | UDP | +------+ +------+ +------+ +------+ |_______________| |______________| Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 7] Internet Draft MTP3-User Adaptation Layer Feb 2000 In the case of SS7 MTP3 network management, it is required that the MTP3-User protocols at ASPs receive indications of SS7 signaling point availability, SS7 network congestion and User Part availability as would be expected 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 made available to the remote MTP3-User lower layer interface at the AN. Note: These indication primitives are also made available to any existing local MTP3-Users at the SG, such as the SCCP in the previous example. For internal SG modelling purposes, this may be accomplished with the use of an implementation-dependent nodal inter-working function within the SG that effectively sits above the MTP3 and delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives received from the MTP Level 3 upper layer interface to the local M3UA-resident management function. This nodal inter-working function has no visible peer protocol with either the ASP or SEP. It is important to clarify that MTP3 management messages such as TFPs or TFAs received from the SS7 network are not "encapsulated" and sent blindly to the ASPs. Rather, the existing MTP3 management procedures are followed within the MTP3 function of the SG to re-calculate the MTP3 route set status and initiate any signaling-route-set-test procedures into the SS7 network. Only when a route set status changes are MTP-PAUSE or MTP-RESUME primitives invoked. These primitives can also be invoked due to local SS7 link set conditions as per existing MTP3 procedures. 1.3.2 Signaling Network Architecture A Signaling Gateway is used to support the transport of ISUP/SCCP signaling traffic received from the SS7 network to multiple distributed Application Nodes (e.g., MGCUs and IP Databases). Clearly, an SG-ASP protocol description cannot in itself meet any performance and reliability requirements for such transport. A physical network architecture is required, with data on the availability and transfer performance of the physical nodes involved in any particular exchange of information. The protocol used must simply be flexible enough allow its operation and management in a variety of physical configurations that will enable Network Operators to meet their performance and reliability requirements. To meet the stringent SS7 signaling reliability and performance requirements for carrier grade networks, these Network Operators should ensure that there is no single point of failure provisioned in the end- to-end network architecture between an SS7 SEP and an IP Application Node. Depending of course on the reliability of the SG and AN functional elements, this can typically be met by the use of redundant SGs, the provision of redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points, and redundant Application Nodes. The distribution of ASPs within the available Application Nodes is also Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 8] Internet Draft MTP3-User Adaptation Layer Feb 2000 important. For a particular Application Server, the related ASPs should be distributed over at least two physical Application Nodes. An example physical network architecture relevant to carrier-grade operation in the IP network domain is shown in Figure 1 below: ******** ************** * *__________________________________________* ******** * AN1 * * * * ASP1 * * * SG1 * SCTP Associations * ******** * * *_______________________ * ******** * * * | * * ASP2 * * * * | * ******** * * * | * ******** * * * | * * ASP3 * * ******** | * ******** * | * . * ******** | * . * * *------------------------------------------* * * * | * ******** * * SG2 * SCTP Associations | * * ASPn * * * *____________ | * ******** * * * | | ************** * * | | ************** * * | |__________________* ******** * AN2 * * | * * ASP1 * * ******** | * ******** * |_____________________________* ******** * * * ASP2 * * * ******** * * ******** * * * ASP3 * * * ******** * * . * * . * * * * ******** * * * ASPn * * * ******** * ************** . . . Figure 1 - Physical Model For carrier grade networks, Operators should ensure that under failure or isolation of a particular AN, stable calls or transactions are not lost. This implies that Application Nodes need, in some cases, to Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 9] Internet Draft MTP3-User Adaptation Layer Feb 2000 share the call/transaction state or be able to pass the call/transaction state between each other. Also, in the case of MGC Application Nodes, coordination may be required with the related Media Gateway to transfer the MGC control for a particular trunk termination. However, this sharing or communication is outside the scope of this document. 1.3.3 SS7 Point Code Representation A Signaling Gateway is charged with representing the IP network nodes into the SS7 network for routing purposes. The SG itself, as a physical node in the SS7 network, must be addressable with an SS7 Destination Point Code for MTP3 Management purposes. This DPC will also be used to address any local MTP3-Users such as an SG-resident SCCP function. An SG may also be addressable with multiple DPCs where the SG is logically partitioned to operate in multiple SS7 network appearances. Alias DPCs may also be used within an SG or an SG network appearance, but SG MTP3 management messages to/from the SS7 network will not use the alias DPCs. The M3UA places no restrictions on the SS7 Destination Point Code (DPC) representation of any of the ASPs. ASPs can be represented under the same DPC of the SG, their own individual Destination Point Codes (DPCs) or grouped with other ASPs for Point Code preservation purposes. A single DPC may be used for the SG and all the ASPs together, if desired. Note: there are potential SS7 traffic engineering restrictions in some arrangements as there is a maximum number of SS7 links within a unique link-set to an adjacent SS7 node. If an ASP or group of ASPs is available to the SS7 network via more than one SG, it is recommended that the ASP(s) be represented by a Destination Point Code that is separate from any SG DPC. This allows some SGs to be viewed from the SS7 network as "STPs", each having a "route" to the same ASP. Under failure conditions where an ASP becomes unavailable from one of the SGs, this approach enables MTP3 route management messaging between the SG and SS7 network, allowing simple re-routing through an alternate SG. 1.3.4 ASP Fail-over Model and Terminology The network address translation and mapping function of the M3UA supports ASP fail-over functions in order to support a high availability of call and transaction processing capability. All ISUP/SCCP messages incoming to an SG from the SS7 network are assigned to a unique Application Server, based on the information in the message. The information examined may be one or more of the MTP DPC, OPC, SLS, or any MTP3-User specific fields such as, for example, the ISUP CIC, SCCP SSN, or TCAP TRID. Some example possibilities are the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN combination. The information used to point to an AS is not limited by the M3UA and none of the examples are mandated. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 10] Internet Draft MTP3-User Adaptation Layer Feb 2000 The Application Server is in practical terms an ordered list of all ASPs configured/registered to process ISUP/SCCP messages within a certain range of routing information, known as a Routing Key. One or more ASPs in the list are normally handling traffic while any others are inactive but available in the event of failure or unavailability of the active ASP(s). The fail-over 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. 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 resident in the list, resident in separate physical Application Nodes and therefore available over different SCTP Associations. For example, in the network shown in Figure 1, all messages to DPC x could be sent to ASP1 in AN1 or ASP1 in AN2. The AS ordered list at SG1 would look like this: Application Server 1 - Routing Key {DPC=x) ASP1/AN1 - Up, Active ASP1/AN2 - Up, Inactive In this "1+1" redundancy case, ASP1 in AN1 would be sent any incoming message with DPC=x. ASP1 in AN2 could be brought to the active state upon failure of, or loss of connectivity to, ASP1/AN1. Both ASPs are Up, meaning that the related SCTP association and far-end M3UA peer is ready. In the process of fail-over or fail-back, it is recommended that in the case of MGCs, stable calls do not fail. It is possible that calls in "transition" may fail, although measures of communication between the MGCs involved may mitigate this. For example, the two MGCs may share call state via shared memory, or may use an MGC-MGC protocol to pass call state information. 1.3.5 UDP Port A request will be made to IANA to assign a well-known UDP port for M3UA. 1.4 Services Provided by the M3UA Layer The M3UA Layer at the ASP provides the equivalent set of primitives at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its local users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at an ASP is unaware that the expected MTP3 services are offered remotely from an MTP3 Layer at an SG and not by a local MTP3 layer. In effect, Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 11] Internet Draft MTP3-User Adaptation Layer Feb 2000 the M3UA extends access to the MTP3 layer services to a remote ASP - the M3UA does not itself provide the MTP3 services so does not duplicate MTP3 procedures. 1.4.1 Support for the transport of MTP3-User Messages The M3UA provides the transport of MTP-TRANSFER primitives across SCTP associations between an SG and an ASP. The MTP-TRANSFER primitives are encoded as ISUP/SCCP messages with attached MTP3 Routing Labels as described in the message format sections of the SCCP and ISUP recommendations. In this way, the SCCP and ISUP messages received from the SS7 network are not re-encoded into a different format for transport to/from the ASP. As well, all the required MTP3 Routing Label information (OPC, DPC, SIO) is available at the ASP as is expected by the ISUP/SCCP layer. For ISUP messages the CIC is available, in its native format. The CIC together with the OPC and DPC uniquely identify all PSTN trunk circuits within a given MTP network instance. Note that M3UA does not itself impose a 272-octet user information block limit as specified by the MTP Level 3. Larger information blocks can be accommodated directly by M3UA/SCTP without the need for an upper layer segmentation/re-assembly procedure such 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 inter-working to a SS7 network that does not support the transfer of larger information blocks to the final destination, as is possible in the Broadband MTP [20]. This will avoid ISUP or SCCP fragmentation requirements at the SG. However, if the SS7 network is provisioned to support the Broadband MTP, the information block size limit may be increased past 272 octets. 1.4.2 Native Management Functions The M3UA may provide management of the underlying SCTP transport protocol to ensure that SG-ASP transport is available to the degree called for by the MTP3-User signaling applications. The M3UA provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the remote peer M3UA. 1.4.3 Inter-working with MTP3 Network Management Functions At the SG, the M3UA must also provide inter-working with MTP3 management functions to support seamless operation of the user SCN signaling applications in the SS7 and IP domains. This includes: - Providing an indication to MTP3-Users at an ASP that a remote destination in the SS7 network is not reachable. - Providing an indication to MTP3-Users at an ASP that a remote destination in the SS7 network is now reachable. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 12] Internet Draft MTP3-User Adaptation Layer Feb 2000 - Providing an indication to MTP3-Users at an ASP that messages to a remote MTP3-User peer in the SS7 network are experiencing SS7 congestion - Providing an indication to MTP3-Users at an ASP that a remote MTP3- User peer is unavailable. The M3UA layer at an ASP may initiate an audit of the availability of remote SS7 destinations. This information is requested from the M3UA at the SG. 1.4.4 Support for the management of SCTP associations between the SG and AN. The M3UA layer at the SG maintains the availability state of all configured remote ASPs, in order to manage the SCTP Associations and the traffic between the SG and ASPs. As well, the active/inactive state of remote ASPs is also maintained - Active ASPs are those currently receiving traffic from the SG. The M3UA layer at either the SG or ASP can be instructed by local management to establish an SCTP association to a peer M3UA 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 M3UA node. The M3UA layer may also need to inform local management of the status of the underlying SCTP associations using the M-SCTP STATUS request and indication primitive. For example, the M3UA may 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 need to inform the local management of the change in availability status of an ASP. This can be achieved using the M-ASP STATUS primitive to change and indicate the status of an ASP. 1.5 Internal Functions Provided in the M3UA Layer 1.5.1 Address Translation and Mapping at the SG M3UA In order to direct messages received from the MTP3 network to the desired IP destination, the SG M3UA must perform address translation and mapping functions using information from the received ISUP/SCCP message. To support this mapping, the SG must maintain a network address translation table, mapping incoming SS7 information to an ordered list of an Application Server Processes. Note that in certain failure and transition cases it is possible that there may not be an active ASP available. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 13] Internet Draft MTP3-User Adaptation Layer Feb 2000 This table is assumed to be dynamic, taking into account the availability status of the individual ASPs in the list, configuration changes, and possible fail-over mechanisms. The M3UA protocol includes messages to convey the availability status of the individual ASPs as input to a fail-over mechanism. Possible SS7 address/routing information that may comprise a routing key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or SCCP Called Party Address. The particular information used in an SG M3UA is implementation dependent. 1.5.2 SG Redundancy It is possible that the ASP could route signaling messages destined to the SS7 network through more than one SG. A primary/back-up case is possible where the unavailability of the ASP Path to a primary SG, or the unavailability of the SS7 destination node from the primary SG, could be used to reroute to a next-preferred SG. Also, a load-sharing case is possible where the signaling messages are load-shared across two (or more) SGs. 1.5.3 SCTP Stream Mapping. The M3UA at both the SG and ASP also supports the assignment of signaling traffic into streams within an SCTP association. Traffic that requires sequencing must be assigned to the same stream. To accomplish this, ISUP/SCCP traffic may be assigned to individual streams based on 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.5.4 Congestion Control. 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). When an SG determines that the transport of SS7 messages to an MTP3 Management Cluster is encountering congestion, the SG may optionally trigger SS7 MTP3 Transfer Controlled management messages to originating SS7 nodes. The triggering of SS7 MTP3 Management messages from an SG is an implementation-dependent function. At an ASP, congestion is indicated to local MTP3-Users by means of an MTP-Status primitive indicating congestion, to invoke appropriate upper layer responses, as per current MTP3 procedures. 1.5.5 Seamless Network Management Inter-working. The M3UA at an SG must maintain knowledge of SS7 node and MTP3 Management Cluster status in their respective domains in order to perform as seamless as possible inter-working of the two domains. For example, SG M3UA knowledge of the availability and/or congestion status of MTP3 Management Cluster and SS7 nodes must be maintained and disseminated in the respective networks so that end-to-end operation is Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 14] Internet Draft MTP3-User Adaptation Layer Feb 2000 transparent to the communicating SCN protocol peers at the SS7 node and ASP. When an SG M3UA determines that the transport of SS7 messages to an MTP3 Management Cluster is encountering congestion, the SG may optionally inform the MTP3 route management function (by an implementation-dependent mechanism). This information is used by the MTP3 to mark the route to the affected destination as congested and to trigger MTP Transfer Controlled (TFC) messages to any SS7 SEPs generating traffic to the congested DPC, as per current MTP3 procedures. When an SG M3UA determines that the transport of SS7 messages to all ASPs in a particular MTP3 Management Cluster is interrupted, the SG M3UA may similarly optionally inform the MTP3 route management function. This information is used by the MTP3 to mark the route to the affected destination as unavailable and to trigger MTP Transfer Prohibited (TFP) messages to the adjacent SS7 nodes which are generating traffic to the unavailable DPC as per current MTP procedures. When an SG M3UA determines that the transport of SS7 messages to an ASP in a particular MTP3 Management Cluster can be resumed, the SG M3UA may similarly optionally inform the MTP3 route management function. This information is used by the MTP3 to mark the route to the affected destination as available and to trigger MTP Transfer Allowed (TFA) messages to the adjacent SS7 nodes as per current MTP3 procedures. Note: In some SS7 network architectures, the sending of TFP and TFA messages from the SG into the SS7 network should be suppressed. For example, in the case where an SG seen by the adjacent SS7 node as an SEP (i.e., in ANSI MTP terms they are connected via A-links or F- links), TFP or TFA messages would not normally be expected by the adjacent SS7 node. 1.5.6 Management Inhibit/Uninhibit Local Management at an ASP or SG may wish to stop traffic across an SCTP association in order 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.7 Active Association Control At an SG, an Application Server list may contain active and inactive ASPs to support ASP loads-haring and fail-over procedures. When, for example, both a primary and a back-up ASP are available, M3UA 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). Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 15] Internet Draft MTP3-User Adaptation Layer Feb 2000 1.6 Definition of M3UA Boundaries 1.6.1 Definition of the boundary between M3UA and an MTP3-User. >From ITU Q.701 [2]: MTP-TRANSFER request MTP-TRANSFER indication MTP-PAUSE indication MTP-RESUME indication MTP-STATUS indication 1.6.2 Definition of the boundary between M3UA and SCTP The upper layer primitives provided by the SCTP are provided in [13] 2.0 M3UA Protocol Elements The general M3UA message format includes a Common Message Header followed by zero or more parameters as defined by the Message Type. For forward compatibility, all Message Types may have attached parameters even if none are specified in this version. 2.1 Common Message Header The protocol messages for MTP3-User Adaptation require a message structure which contains a version, message type, message length, and message contents. This message header is common among all signaling protocol adaptation layers: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Spare | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | All fields in an M3UA message MUST be transmitted in the network byte order, unless otherwise stated. 2.1.1 M3UA Protocol Version The version field (Vers.) contains the version of the M3UA adaptation layer. The supported versions are: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 16] Internet Draft MTP3-User Adaptation Layer Feb 2000 0000 0001 Release 1.0 protocol 2.1.2 Message Types The following list contains the message types for the defined messages. Transfer Messages Data 0101 SS7 Signaling Network Management (SSNM) Messages Destination Unavailable (DUNA) 0201 Destination Available (DAVA) 0202 Destination State Audit (DAUD) 0203 SS7 Network Congestion State (SCON) 0204 Destination User Part Unavailable (DUPU) 0205 Application Server Process Maintenance (ASPM) messages ASP Up 0301 ASP Down 0302 ASP Active 0401 ASP Inactive 0402 Management (MGMT) Messages Error 0000 2.1.3 Message Length The Message Length defines the length of the message in octets, not including the header. 2.2 ISUP/SCCP Transfer Messages The following section describes the ISUP/SCCP Transfer messages and parameter contents. The general message format includes a Common Message Header together with a list of zero or more parameters as defined by the Message Type. All Message Types can have attached parameters. 2.2.1 Data Message The Data message contains SS7 MTP3-User protocol data, which is an MTP- TRANSFER primitive, including the complete MTP3 Routing Label. The Data message contains the following parameters: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 17] Internet Draft MTP3-User Adaptation Layer Feb 2000 PROTOCOL IDENTIFIER (Optional) NETWORK APPEARANCE (Optional) PROTOCOL DATA The format for the Data Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Identifier parameter identifies explicitly the MTP3-User Part being transported, where the SCN protocol carried is not known implicitly in the context of a particular SCTP association/stream or Network Appearance/SIO. The Protocol Id defines the protocol type, variant, and version, and thereby specifies the components and encoding of the Protocol Data parameter. Protocol Ids will be maintained by IANA outside of this document and may be registered on an "as needed" basis. The Protocol Id is not required in Data messages if the Protocol Id information is pre-configured or identified at Association or Path establishment. Ed Note: The Protocol Id format is an OID as defined in ..... The Network Appearance identifies the SS7 network context for the message, for the purposes of logically separating the signaling traffic between the SG and the Application Server Processes over common SCTP Associations. An example is where an SG is logically partitioned to appear as an element in four different national networks. A Network Appearance implicitly defines the SS7 Destination Point Code, Network Indicator and MTP3 protocol type/variant/version used within each network. The format is an ASCII string, the values of which are assigned Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 18] Internet Draft MTP3-User Adaptation Layer Feb 2000 according to network operator policy. The Network Appearance string should be padded to 32-bit boundaries. The Protocol Data field contains the MTP3-User application message, which is in effect an MTP-TRANSFER primitive. As defined for a specific value of the Protocol Identifier, this will include the MTP- User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and the SIO (Service Indicator, Network Indicator & optional Message Priority codes). In the case of ISUP messages, the Circuit Identification Code is also included. 2.3.2 SS7 Signaling Network Management (SSNM) Messages 2.3.2.1 Destination Unavailable (DUNA) The DUNA message is sent from the SG to all concerned ASPs to indicate that the SG has determined that an SS7 destination is unreachable. The MTP3-User at the ASP is expected to stop traffic to the affected destination through the SG initiating the DUNA. The DUNA message contains the following parameters: Protocol Identifier (Optional) Network Appearance (Optional) Affected Destination Point Code Info String (Optional) The format for DUNA Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (MTP) Protocol Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Spare | Affected DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 19] Internet Draft MTP3-User Adaptation Layer Feb 2000 The Protocol Identifier parameter is defined similarly to Section 2.2.1 but in this case defines the MTP3 version/variant. In this context it defines the format of the Affected DPC parameter. By identifying the MTP variant and version, the point code length (e.g., 14-, 16-, or 24- bit) and sub-field definitions (e.g., ANSI network/cluster/member, ITU- international zone/region/signal_point, many national field variants, ...) can be determined. The Network Appearance is defined as in Section 2.2.1 The INFO String parameter can carry any meaningful 8-BIT ASCII character string along with the message. Length of the INFO String parameter is from 0 to 255 characters. No procedures are presently identified for its use but the INFO String may be used by Operators to identify in text form the location reflected by the Affected DPC for debugging purposes. The Affected DPC is provisionally a three-octet parameter to allow 14-, 16- and 24-bit binary formatted SS7 Point Codes. 2.3.2.2 Destination Available (DAVA) The DAVA message is sent from the SG to all concerned ASPs to indicate that the SG has determined that an SS7 destination is now reachable. The ASP MTP3-User protocol is expected to resume traffic to the affected destination through the SG initiating the DUNA. The DAVA message contains the following parameters: Protocol Identifier (Optional) Network Appearance (Optional) Affected Destination Point Code Info String (Optional) The format and description of DAVA Message parameters is the same as for the DUNA message (See Section 2.3.2.1.) 2.3.2.3 Destination State Audit (DAUD) The DAUD message can be sent from the ASP to the SG to query the availability state of the SS7 routes to an affected destination. A DAUD may be sent periodically after the ASP has received a DUNA, until a DAVA is received. The DAUD can also be sent when an ASP recovers from isolation from the SG. The DAUD message contains the following parameters: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 20] Internet Draft MTP3-User Adaptation Layer Feb 2000 Protocol Identifier (Optional) Network Appearance (Optional) Affected Destination Point Code Info String (Optional) The format and description of DAUD Message parameters is the same as for the DUNA message (See Section 2.3.2.1.) 2.3.2.4 SS7 Network Congestion (SCON) The SCON message can be sent from the SG to all concerned ASPs to indicate that the congestion level in the SS7 network to a specified destination has changed. The SCON message contains the following parameters: Protocol Identifier (Optional) Network Appearance (Optional) Affected Destination Point Code Info String (Optional) Congestion Level (Optional) The format for SCON Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cong. Level | Affected DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 21] Internet Draft MTP3-User Adaptation Layer Feb 2000 The format and description of the Protocol Identifier, Network Appearance, Affected DPC and Info String parameters is the same as for the DUNA message (See Section 2.3.2.1.) The valid values for the optional Congestion Level parameter are shown in the following table. Value Description 00 No Congestion or Undefined 01 Congestion Level 1 02 Congestion Level 2 03 Congestion Level 3 The congestion levels are as defined in the national congestion method in the ITU MTP recommendation [14] or in the ANSI MTP standard [15]. For MTP versions/variants without congestion levels, for example the ITU international method, the parameter is always Undefined. 2.3.2.5 Destination User Part Unavailable (DUPU) The DUPU message is used by a SG to inform an ASP that a remote peer MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. The DUPU message contains the following parameters: Protocol Identifier (Optional) Network Appearance (Optional) Affected Destination Point Code Info String (Optional) Reason The format for DUPU Message parameters is as follows: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 22] Internet Draft MTP3-User Adaptation Layer Feb 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Affected DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the Protocol Identifier, Network Appearance, Affected DPC and Info String parameters is the same as for the DUNA message (See Section 2.3.2.1.) The valid values for Reason are shown in the following table. Define Value Description UPU-Unknown 01 MTP User Part Unavailable, No Reason Given UPU-Unequipped 02 MTP User Part Unavailable, Unequipped UPU-Inaccessible 03 MTP User Part Unavailable, Inaccessible 2.3.3 Application Server Process Maintenance (ASPM) Messages 2.3.3.1 ASP Up (ASPUP) The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer that the Adaptation layer is ready to receive traffic or maintenance messages. The ASPUP message contains the following parameters: Adaptation Layer Identifer (optional) Protocol Identifier (optional) INFO String (optional) Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 23] Internet Draft MTP3-User Adaptation Layer Feb 2000 The format for ASPUP Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adaptation Layer Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Protocol Identifier and Info String parameters is the same as for the DUNA message (See Section 2.3.2.1.) The optional Adaptation Layer Identifier (ALI) is a string that identifies the adaptation layer. This string must be set to "M3UA" which results in a length of 4. The ALI would normally only be used in the initial ASP Up message across a new SCTP association to ensure both peers are assuming the same adaptation layer protocol. Note: Strings are padded to 32-bit boundaries. The length field indicates the end of the string. 2.3.3.2 ASP Down (ASPDN) The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer that the adaptation layer is not ready to receive traffic or maintenance messages. The ASPDN message contains the following parameters: Reason INFO String (Optional) The format for the ASPDN message parameters is as follows: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 24] Internet Draft MTP3-User Adaptation Layer Feb 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Info String parameter is the same as for the DUNA message (See Section 2.3.2.1.) The Reason parameter indicates the reason that the remote M3UA adaptation layer is unavailable. The valid values for Reason are shown in the following table. Value Description 0x1 Processor Outage 0x2 Management Inhibit 2.3.3.3 ASP Active (ASPAC) The ASPAC message is sent by an ASP to indicate to an SG that it is Active and ready to be used. The ASPAC message contains the following parameters: Routing Context (Optional) INFO String (Optional) The format for the ASPAC message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Context* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 25] Internet Draft MTP3-User Adaptation Layer Feb 2000 The Type parameter identifies the ASPAC as an Over-ride or Load-share Active message. The valid values for Type are shown in the following table. Value Description 0x1 Over-ride 0x2 Load-share Within a particular Routing Context, only one Type can be used. An SG that receives an ASPAC with an incorrect type for a particular Routing Context will respond with an Error Message. The optional Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is conigured to receive. There is one-to-one relationship between an index entry and an AS Name. Because an AS can only appear in one Network Appearance, the Network Appearance parameter is not required in the ASPAC message An Application Server Process may be configured to process traffic for more than one logical Application Server. From the perspective of an ASP, a Routing Context defines a range of signaling traffic that the ASP is currently configured to receive from the SG. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signaling traffic, identified by separate SS7 DPC/OPC/CIC_ranges. The format and description of the optional Info String parameter is the same as for the DUNA message (See Section 2.3.2.1.) 2.3.3.4 ASP Inactive (ASPIA) The ASPIA message is sent by an ASP to indicate to an SG that it is no longer an active ASP to be used from within a list of ASPs. The SG will respond with an ASPIA message and either discard incoming messages or buffer for a timed period and then discard. The contains the following parameters: Routing Context (Optional) INFO String (Optional) The format for the ASPIA message parameters is as follows: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 26] Internet Draft MTP3-User Adaptation Layer Feb 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xx) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INFO String* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format and description of the optional Routing Context and Info String parameters is the same as for the ASPAC message (See Section 2.3.3.3.) 2.3.4 Management Messages 2.3.4.1 Error (ERR) The ERR message is sent when an invalid value is found in an incoming message. The ERR message contains the following parameters: Error Code The format for the ERR message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code can be one of the following values: Invalid Version 0x1 Invalid Network Appearance 0x2 Invalid SCN Version 0x3 Invalid Adaptation Layer Identifier 0x4 Invalid Stream Identifier 0x5 Invalid Message Type 0x6 3.0 Procedures Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 27] Internet Draft MTP3-User Adaptation Layer Feb 2000 The M3UA layer needs to respond to various local primitives it receives from other layers as well as the messages that it receives from the peer M3UA layers. This section describes the M3UA procedures in response to these events. 3.1 Procedures to support the services of the M3UA layer The services of the M3UA layer are described in Section 1.4.1. These procedures support the M3UA transport of MTP3-User/MTP3 boundary primitives. 3.1.1 Receipt of Local primitives On receiving an MTP-Transfer primitive from an upper layer, or the nodal inter-working function at an SG, the M3UA layer will send a corresponding Data message (see Section 2) to its M3UA peer. The M3UA layer must fill in various fields of the common and specific headers correctly. At an SG, the M3UA address translation and mapping function determines the logical Application Server based on the information in the incoming message. From an ordered list of ASPs within the AS table, the Active ASP is selected and the Data message is constructed and issued on the corresponding SCTP Association. If more than one ASP is active (i.e., traffic is to be load-shared across all the active ASPs), one of the active ASPs from the list is selected. The selection algorithm is implementation dependent but could be based on, for example, the SLS or ISUP CIC. In addition, the message needs to be sent on the appropriate SCTP stream, taking care to conserve the message sequencing needs of the signaling application. Ed Note: Further description of stream assignment and/or examples are required 3.2 Procedures to support the M3UA services in Section 1.4.2 3.2.1 Layer Management primitives procedures On receiving these primitives from the local layer management, the M3UA layer will send the corresponding management message (Error) to its peer. The M3UA layer must fill in the various fields of the common and specific headers correctly. 3.2.2 Receipt of Peer Management messages Upon receipt of Management messages, the M3UA layer must invoke the corresponding Layer Management primitive indications (M-ERROR ind.) to Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 28] Internet Draft MTP3-User Adaptation Layer Feb 2000 the local layer management. 3.3 Procedures to support the M3UA services in Section 1.4.4 These procedures support the M3UA management of SCTP Associations and ASP Paths between SGs and ASPs 3.3.1 State Maintenance The M3UA layer on the SG needs to maintain the state of each ASP as input to the SGs address translation and mapping function. 3.3.1.1 ASP States The state of each ASP is maintained in the M3UA layer in the SG. The state of an ASP changes due to events. The events include: * Reception of messages from peer M3UA layer * Reception of indications from the SCTP layer The ASP state transition diagram is shown in Figure 4. The possible states of an ASP are: ASP-DOWN: The Application Server Process is unavailable. Initially all ASPs will be in this state. ASP-UP: The Application Server Process is available but application traffic is stopped. ASP-ACTIVE: The Application Server Process is available and application traffic is active (for a particular Routing Context or set of Routing Contexts). Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 29] Internet Draft MTP3-User Adaptation Layer Feb 2000 Figure 4: ASP State Transition Diagram +-------------+ |-------->| | | | ASP-ACTIVE | | +-------------+ | ^ | | ASP | | ASP | Active | | Inactive | | v | +-------------+ ASP Down / | | | SCTP CDI | | ASP-UP | | +-------------+ | ^ | | ASP | | ASP Down / | Up | | SCTP CDI | | v | +-------------+ | | | |-------->| | | ASP-DOWN | +-------------+ SCTP CDI: The local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this indication when it detects the loss of connectivity to the ASP's SCTP layer. 3.3.1.2 AS States The state of the AS is maintained in the M3UA layer on the SG. The state of an AS changes due to events. These events include: * ASP state transitions * Recovery timer triggers The possible states of an AS are: AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. AS-UP: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP-UP state, but none in the ASP-Active state). AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that one ASP is in the ASP-ACTIVE state. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 30] Internet Draft MTP3-User Adaptation Layer Feb 2000 AS-PENDING: An active ASP has transitioned from active to inactive or down and it was the last remaining active ASP in the AS. A recovery timer T(r) will be started and all incoming SCN messages will be queued by the SG. If an ASP becomes active before T(r) expires, the AS will move to AS-ACTIVE state and all the queued messages will be sent to the active ASP. If T(r) expires before an ASP becomes active, the SG stops queuing messages and discards all previously queued messages. The AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. Figure 5: AS State Transition Diagram +----------+ one ASP trans ACTIVE +-------------+ | |------------------------>| | | AS-UP | | AS-ACTIVE | | | | | | |< -| | +----------+ \ / +-------------+ ^ | \ Tr Trigger / ^ | | | \ at least one / | | | | \ ASP in UP / | | | | \ / | | | | \ / | | | | \ /---/ | | one ASP | | \ / one ASP | | ACTIVE ASP trans | | all ASP \-/----\ trans to | | trans to UP or to UP | | trans to / \ ACTIVE | | DOWN | | DOWN / \ | | | | / \ | | | | / \ | | | | /all ASP \ | | | v / trans to \ | v +----------+ / DOWN \ +-------------+ | |<--/ -| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<------------------------| | +----------+ Tr Trigger no ASP +-------------+ in UP state or Tr = Recovery Timer 3.3.2 ASPM procedures for primitives Before the establishment of an SCTP association the ASP state at both the SG and ASP is assumed to be "Down". Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 31] Internet Draft MTP3-User Adaptation Layer Feb 2000 When the M3UA layer receives an M-SCTP ESTABLISH request primitive from the Layer Management, the M3UA layer will try to establish an SCTP association with the remote M3UA peer. Upon reception of an eventual SCTP-Communication Up confirm primitive from the SCTP, the M3UA layer will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. Alternatively, if the remote M3UA-peer establishes the SCTP association first, the M3UA layer will receive an SCTP Communication Up indication primitive from the SCTP. The M3UA layer will then invoke the primitive M-SCTP ESTABLISH indication to the Layer Management. Once the SCTP association is established, The M3UA layer at an ASP will then find out the state of its local M3UA-user from the Layer Management using the primitive M-ASP STATUS. Based on the status of the local M3UA-User, the local ASP M3UA Application Server Process Maintenance (ASPM) function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. If the M3UA layer subsequently receives an SCTP-Communication Down indication from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP STATUS indication primitive. The state of the ASP will be moved to "Down" at both the SG and ASP. At an ASP, the Layer Management may try to reestablish the SCTP association using M-SCTP ESTABLISH request primitive. 3.3.3 ASPM procedures for peer-to-peer messages 3.3.3.1 ASP-Up [Ed Note: text required to specify what SG does before first ASP-Up received] The SG will mark the path as up if an explicit ASP UP (ASPUP) message is received and internally the path is allowed to come up (i.e., not in a locked local maintenance state). An ASP UP (ASPUP) message will be sent to acknowledge the received ASPUP. The SG will respond to a ASPUP with a ASPDN message if the path is in a locked maintenance state. The SG will send a ASPUP message in response to a received ASPUP message from the ASP even if that path was already marked as UP at the SG. The paths are controlled by the ASP. The SG will only send ASPUP in response to the reception of a ASPUP message. The ASP will send ASPUP messages every 2 seconds until the path comes up (i.e. until it receives a ASPUP message from the SG for that path). The ASP may decide to reduce the frequency (say to every 5 seconds) if Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 32] Internet Draft MTP3-User Adaptation Layer Feb 2000 the an acknowledgement is not received after a few tries. The ASP should wait for the ASPUP message from the SG before transmitting ASP maintenance messages (ASPIA or ASPAC) or M3UA messages or it will risk message loss. The ASPUP message received from the SG is not acknowledged by the ASP. 3.3.3.2 ASP Down The SG will mark the ASP as down and send an ASPDN message to the ASP if one of the following events occur: - an ASP Down(ASPDN) message is received from the ASP, - the ASP is locked by local maintenance at the SG. The SG will also send a ASPDN message when the ASP is already down and a ASPDN) message is received from the ASP. The ASP will send ASPDN whenever it wants to take down a ASP. Since the ASPDN messages to the SG or the ASPDN responses from the SG can be lost (for example, during fail-over), the MGC can send ASPDN messages every 2 seconds until the path comes down (i.e. until it receives a ASPDN message from the SG for that path). 3.3.3.3 ASP Version Control If a ASP Up message with an unknown version is received, the receiving end will respond with an Error message. This will indicate to the sender which version the receiving node supports. This is useful when protocol version upgrades are being performed. A node with the newer version should support the older versions used on other nodes it is communicating with. The version field in the Error message header associated will indicate the version supported by the node. 3.3.3.4 ASP Active When an ASP Active (ASPAC) message is received, the SG will start routing to that ASP. Reception of a ASPAC message overrides any previous ASPAC messages and results in the ASP associated with the ASPAC message to become the newly active ASP. 3.3.3.5 ASP Inactive When a ASPIA message is received, message transmission to that ASP ceases. The SG will either discard all incoming messages or start buffering the incoming messages for T(r)seconds after which messages will be discarded. If the ASP is down, all of the Paths that were supported by that ASP Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 33] Internet Draft MTP3-User Adaptation Layer Feb 2000 are, by default, down. 3.4 Procedures to support the M3UA services in Section 1.4.3 3.4.1 At an SG On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication primitive from the inter-working function at an SG, the M3UA layer will send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message (see Section 2) to the concerned M3UA peers. The M3UA layer must fill in various fields of the common and specific headers correctly. The M3UA address translation and mapping function determines the set of ASPs to be informed based on the network appearance for which the indication is relevant. All ASPs configured to send/receive traffic within a particular network appearance are informed. If the SG operates within a single network appearance, then all ASPs are informed. It may be possible to suppress DUPU messages to ASPs that do not implement an MTP3-User protocol peer for the affected MTP3-User, but this is not mandatory. In addition, the DUNA, DAVA, SCON messages need to be sent on a sequenced stream as these primitives should arrive in order. This is not required for the DUPU message, which may optionally be sent un- sequenced. 3.4.2 At an ASP At an ASP, upon receiving an SSNM message from the remote M3UA Peer, the M3UA layer invokes the appropriate primitive indications to the M3UA-User. Local management is informed but no state is maintained in the M3UA layer. 4.0 Examples of M3UA Procedures 4.1 Establishment of Association and Traffic between SGs and ASPs 4.1.1 Single ASP in an Application Server ("1+0" sparing) An example of the message flows for establishing an active association between an SG and an ASP is shown below. It is assumed that an SCTP association is already set-up. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 34] Internet Draft MTP3-User Adaptation Layer Feb 2000 SG ASP1 | |<---------ASP Up---------| |-------ASP Up (Ack)----->| | | |<-------ASP Active-------| |----ASP Active (Ack)---->| | | 4.1.2 Two ASPs in Application Server ("1+1" sparing) Establishment of Associations between an SG and Multiple ASPs in the same Application Server (Primary/Back-up case). In this case ASP1 will be the primary ASP for the AS and ASP2 will be a standby in the event of failure of the withdrawal from service of ASP1. ASP could act as a hot, warm, or cold standby depending on the extent to which ASP1 and ASP2 share call state or can communicate call state under failure/withdrawal events. SG ASP1 ASP2 | | | |<---------ASP Up---------| | |-------ASP Up (Ack)----->| | | | | |<------------------------------ASP Up---------------| |-----------------------------ASP Up (Ack)---------->| | | | ... | | | |<-------ASP Active-------| | |----ASP Active (Ack)---->| | | | | 4.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing case) SG ASP1 ASP2 | | | |<---------ASP Up---------| | |-------ASP Up (Ack)----->| | | | | |<------------------------------ASP Up---------------| |-----------------------------ASP Up (Ack)---------->| | | | ... Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 35] Internet Draft MTP3-User Adaptation Layer Feb 2000 | | | |<--ASP Active (Ldshr)----| | |----ASP Active (Ack)---->| | | | | |<----------------------------ASP Active (Ldshr)-----| |-----------------------------ASP Active (Ack)------>| | | | 4.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing case) SG ASP1 ASP2 ASP3 | | | | |<------ASP Up-------| | | |----ASP Up (Ack)--->| | | | | | | |<--------------------------ASP Up-------| | |------------------------ASP Up (Ack)--->| | | | | | |<---------------------------------------------ASP Up--------| |--------------------------------------------ASP Up (Ack)--->| | | | | ... | | | | |<-ASP Act. (Ldshr)--| | | |---ASP Act. (Ack)-->| | | | | | | |<--------------------ASP Act. (Ldshr)---| | |----------------------ASP Act. (Ack)--->| | | | | | 4.3 ASP Traffic Fail-over Examples 4.3.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride) Following on from the example in Section 4.1.2, and ASP withdraws from service: SG ASP1 ASP2 | | | |<-----ASP Inactive-------| | |---ASP Inactive (Ack)--->| | |----------------------------ASP Active (Optional)-->| | | | |<------------------------------ ASP Active----------| |-----------------------------ASP Active (Ack)------>| | | Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 36] Internet Draft MTP3-User Adaptation Layer Feb 2000 Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or detection of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange would not occur. 4.3.2 (1+1 Sparing, Back-up Over-ride) Following on from the example in Section 4.1.2, and ASP2 wishes to over-ride ASP1 and take over the traffic: SG ASP1 ASP2 | | | |<------------------------------ ASP Active----------| |-----------------------------ASP Active (Ack)------>| | | | |------ASP Inactive------>| | |<--ASP Inactive (Ack)----| | | | | 4.3.3 (n+k Sparing, Load-sharing case, withdrawal of ASP) Following on from the example in Section 4.1.4, and ASP1 withdraws from service: SG ASP1 ASP2 ASP3 | | | | |<----ASP Inact.-----| | | |--ASP Inact. (Ack)->| | | | | | | |---------------------------------------ASP Act. (Optional)->| | | | | |<-----------------------------------------ASP Act. (Ldshr)--| |-------------------------------------------ASP Act. (Ack)-->| | | | | Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive message exchange would not occur. 4.4 M3UA/MTP3-User Boundary Examples 4.4.1 At an ASP This section describes the primitive mapping from the MTP3 User to M3UA at an ASP. 4.4.1.1 Support for MTP-Transfer When the MTP3-User has data to send into the SS7 network, it will use the MTP-Transfer indication primitive. The M3UA on the ASP will do the following when it receives an MTP-Transfer: Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 37] Internet Draft MTP3-User Adaptation Layer Feb 2000 ? Determine the correct SG ? Determine the correct association to the chosen SG ? Determine the correct stream in the association (e.g., based on SLS) ? Map the MTP-Transfer into the Payload of a Data message ? Send the Data message to the remote M3UA peer, over the SCTP association SG ASP | | |<-----Data Message-------|<--MTP-Transfer req. | | or | | |------Data Message------>|---MTP-Transfer ind.? | | 4.4.1.2 Support for ASP Querying of SS7 Destination States There are situations such as temporary loss of connectivity to the SG that may cause the M3UA on the ASP to audit SS7 destination availability states. Note: there is no primitive for the MTP3-User to request this audit from the M3UA as this is initiated by an internal M3UA management function. The M3UA on the MGC / AN would send Destination State Audit (DAUD) messages for each of the destinations that the MGC / AN supports. SG ASP | | |<-----DAUD Message ------| |<-----DAUD Message ------| |<-----DAUD Message ------| | | | | 4.4.2 At an SG This section describes the primitive mapping from the MTP3 Upper layer boundary to the M3UA at the SG. The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the MTP3 upper layer interface at the SG need to be made available to the remote MTP3-User lower layer interface at the ASP. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 38] Internet Draft MTP3-User Adaptation Layer Feb 2000 4.4.2.1 Destination Unavailable The MTP3 on the SG will generate an MTP-PAUSE primitive when it determines locally that an SS7 destination is unreachable. The M3UA will map this primitive to a Destination Unavailable (DUNA) message. It will determine which ASP(s) to send the DUNA based on the Network Appearance information. SG ASP | | --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.--> | | 4.4.2.2 Destination Available The MTP3 on the SG will generate an MTP-RESUME primitive when it determines locally that an SS7 destination that was previously unreachable is now reachable. The M3UA will map this primitive to a Destination Unavailable (DAVA) message. It will determine which ASP(s) to send the DUNA based on the Network Appearance information. SG ASP | | --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.--> | | 4.4.2.3 SS7 Network Congestion The MTP3 on the SG will generate an MTP-STATUS primitive when it determines locally that the route to an SS7 destination is congested. The M3UA will map this primitive to a SS7 Network Congestion State (SCON) message. It will determine which ASP(s) to send the DUPU to based on the intended Application Server. SG ASP | | --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.--> | | 4.4.2.4 Destination User Part Unavailable The MTP3 on the SG will generate an MTP-STATUS primitive when it determines locally that an SS7 destination User Part is unavailable. The M3UA will map this primitive to a Destination User Part Unavailable (DUPU) message. It will determine which ASP(s) to send the DUPU to based on the intended Application Server. Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 39] Internet Draft MTP3-User Adaptation Layer Feb 2000 SG ASP | | --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.--> | | 5.0 Security M3UA relies upon IPSEC to ensure confidentiality of user payload. Consult [RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Atkinson, November 1998] for more information on configuring IPSEC services. 6.0 Acknowledgements The authors would like to thank John Loughney, Neil Olson, Norm Glaude, and Michael Tuexen for their valuable comments and suggestions. 7.0 References [1] RFC 2719, "Framework Architecture for Signaling Transport" [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) - ISDN User Part (ISUP)' [3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services" [5] ITU-T Recommendations Q.711-714, 'Signalling System No. 7 (SS7) - Signalling Connection Control Part (SCCP)' [6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection Control Part' [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP) (connectionless and connection-oriented class 2) to support international interconnection; Part 1: Protocol specification" [8] ITU-T Recommendations Q.720, 'Telephone User Part' [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - Transaction Capabilities (TCAP) [10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities Application Part' Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 40] Internet Draft MTP3-User Adaptation Layer Feb 2000 [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification" [12] RANAP [13] Simple Control Transport Protocol , Dec. 1999, Work in Progress [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' [15] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol specification" [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for signaling at the Network Node Interface (SSCF at NNI) [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) [19] MTP2-User Adaptation Layer , Nov. 1999, Work in Progress [20] ITU-T Recommendation Q.2210 'B-ISDN MTP' 5.0 Author's Addresses Lyndon Ong Guy Mousseau Nortel Networks Nortel Networks 4401 Great America Pkwy 3685 Richmond Rd Santa Clara, CA, USA 95054 Nepean, Ontario, Canada K2H 5B7 long@nortelnetworks.com Greg Sidebottom Ian Rytina Nortel Networks Ericsson Australia 3685 Richmond Rd, 37/360 Elizabeth Street Nepean, Ontario, Canada K2H 5B7 Melbourne, Vic 3000 Australia gregside@nortelnetworks.com ian.rytina@ericsson.com Hanns Juergen Schwarzbauer Ken Morneault SIEMENS AG Cisco Systems Inc. Hofmannstr. 51 13615 Dulles Technology Rd 81359 Munich, Germany Herndon, VA 20171 USA HannsJuergen.Schwarzbauer@icn.siemens.de kmorneau@cisco.com Malleswar Kalla Telcordia Technologies MCC 1J211R 445 South Street Morristown, NJ, USA 07960 EMail: kalla@research.telcordia.com This draft expires July 2000.