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 8 October 1999 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 transport of 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, or as seamless as possible, 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 but could also be used between two SGs if desired. It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. NOTE: THIS DRAFT REPLACES 1 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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 2 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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). The delivery mechanism should meet the following criteria: * Support for transfer of SS7 MTP3-User Part messages (e.g., ISUP, SCCP, TUP, etc.) * Support for the seamless operation of MTP3-User peers * Support for the management of SCTP transport associations between an SG and an MGC or IP Database) * Support for the asynchronous reporting of status changes to management In other words, the SG will terminate SS7 MTP2 and MTP3 protocols and deliver ISUP, SCCP and/or any other MTP3-User protocols to IP-resident Application Server Processes over an SCTP transport association 1.2 Terminology Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a virtual switch handling all call processing for a particular SS7 OPC/DPC/CIC_range. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, ...). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances. Application Server Process Path (ASP Path or just Path) - A Path to a remote Application Server Process instance. A Path maps 1:1 to an SCTP association Application Server Cluster (ASC) - A group of one or more Application Servers represented to the SS7 network by the same SS7 Point Code. An SG cannot send MTP Level 3 management messages relating to the availability/congestion status of an SS7 destination in the IP domain unless the status is true across all members of the Application Server Cluster. Association - An association refers to an SCTP association. The association will provide 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 a next-preferred Application Server Process within an Application Server in the event of failure or unavailability of the currently used 3 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 Application Server Process (e.g., from primary MGC to back-up MGC). Fail-over may also apply upon the return to service of a previously unavailable Application Server Process. MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Stream - A stream refers to an SCTP stream. 1.3 Signaling Transport Architecture The architecture that has been defined for SCN signaling transport over IP uses multiple components, including an IP transport protocol, 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. In reference to the SIGTRAN framework architecture [xx], This document defines an MTP3-User adaptation module that is suitable for the transport of SS7 ISDN User Part (ISUP) and Signalling Connection Control Part (SCCP) messages but could be used equally to transport other SS7 MTP3-User Part messages such as, for example, TUP. Note: SCCP-Users (e.g., INAP/TC or ISUP) are supported implicitly as SCCP payload. In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling is transmitted and received over a standard SS7 network interface, using the SS7 Message Transfer Part (MTP) to provide transport of ISUP/SCCP signaling messages to and from an SS7 Signaling End Point (SEP) or Signaling Transfer Point (STP). The SG then provides interworking of transport functions with IP Signaling Transport, in order to transfer the ISUP/SCCP signaling messages to and from the ASP where the peer ISUP/SCCP protocol layer exists. Three general cases are shown below to cover the routing options in the event of ISUP or SCCP transport across the SG as shown below: 1.3.1 Case 1: ISUP transport ****** SS7 ****** IP ****** *SEP *-----------* SG *-----------*ASP * ****** ****** ****** +----+ +----+ |ISUP| |ISUP| +----+ +---------+ +----+ |MTP | |MTP |M3UA| |M3UA| |L3 | |L3 +----+ +----+ |L2 | |L2 |SCTP| |SCTP| |L1 | |L1 +----+ +----+ | | | |UDP | |UDP | +----+ +---------+ +----+ SEP - SS7 Signaling End Point SCTP - Simple Control Transport Protocol [5] 4 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 Note: The use of MTP Level 2 signaling links in the SS7 network is shown as an example. ATM-based High Speed Links could also be used, using MTP3/SSCF/SSCOP [3,4]. For that matter, it is possible that IP- based links could present, using MTP3/M2UA/SCTP. Also, STPs may be present in the SS7 path between the SEP and the SG. To enable a seamless, or as seamless as possible, operation of the MTP3-User peers in the SS7 and IP domains, the SG implements for modeling purposes a nodal interworking function. The interworking function purpose is to deliver MTP-TRANSFER indication primitives received from the MTP Level 3 upper layer interface to an M3UA-resident network address translation and mapping function for ongoing routing to the final IP destination. This internal SG function also delivers MTP- TRANSFER request primitives to the MTP Level 3 upper layer interface from the M3UA network address translation and mapping function for ongoing MTP Level 3 routing to the SS7 node. This nodal interworking function is described for modeling purposes only - it is a nodal implementation-dependent function that does not affect the peer protocol exchanges. 1.3.2 Case 2: SCCP transport where an SCCP function at the SG is invoked: ****** SS7 ****** IP ******* *SEP *-----------* SG *------------* ASP * * or * * * * * *STP * * * * * ****** ****** ******* +----+ +---------+ +-----+ |SCCP| | SCCP | |SCCP | +----+ +---------+ +-----+ |MTP | |MTP |M3UA| |M3UA | |L3 | |L3 +----+ +-----+ |L2 | |L2 |SCTP| |SCTP | |L1 | |L1 +----+ +-----+ | | | |UDP | | UDP | +----+ +---------+ +-----+ Note: An SEP can be an SCP or SSP In this case, the SCCP at the SG performs Global Title Translation (GTT) for messages in either direction that do not yet have a final SS7 MTP Destination Point Code address (and possibly SCCP Subsystem). Use of the SCCP at the SG will avoid a requirement for a GTT function within the M3UA protocol. The SG nodal interworking function delivers an MTP-TRANSFER indication primitive incoming from the SS7 network to 5 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 an M3UA-resident network address translation and mapping function for ongoing routing to the final IP destination, but only after the SCCP GTT has been performed and a new Destination Point Code (and possibly Subsystem) have been determined. The M3UA network address translation and mapping function then determines the final IP destination. It is possible that the SCCP GTT result could be a non-final GTT result and M3UA would then actually be determining an IP destination that will perform the next GTT. Similarly messages from the IP network can be addressed to the SG for SCCP GTT. The SG nodal interworking function would deliver these MTP- TRANSFER request primitives to the SCCP from M3UA. The SCCP GTT will then determine an SS7 Destination Point Code (and possibly Subsystem) before delivery into the SS7 network. It is possible that after SCCP GTT the DPC (and possibly Subsystem) result could represent an IP-based ASP and be sent by the nodal interworking function back to the M3UA- resident network address translation and mapping function for ongoing routing to an IP destination. 1.3.3 Case 3: SCCP transport where an SCCP function at the SG is not invoked: ****** SS7 ****** IP ******* *SEP *-----------* SG *------------* ASP * * or * * * * * *STP * * * * * ****** ****** ******* +----+ +-----+ |SCCP| |SCCP | +----+ +---------+ +-----+ |MTP | |MTP |M3UA| |M3UA | |L3 | |L3 +----+ +-----+ |L2 | |L2 |SCTP| |SCTP | |L1 | |L1 +----+ +-----+ | | | |UDP | | UDP | +----+ +---------+ +-----+ For this case, the SG nodal interworking function operates as in Case 1. 1.3.4 UDP Port A request will be made to IANA to assign a UDP port for M3UA. 1.4 Services Provided by the M3UA Layer 1.4.1 Support for the transport of MTP3-User/MTP boundary primitives 6 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 The SS7 MTP Level 3 upper layer interface is retained at the ASP, so the M3UA protocol layer is required to provide the equivalent set of services to its users as provided by the MTP Level 3. This includes the following services: M3UA provides the ability to transfer MTP3-User messages (in this Case, ISUP/SCCP PDUs) across SCTP associations. Note that M3UA does not itself impose a 256 octet user information block limit as specified by the MTP Level 3. Larger blocks can be accommodated directly by M3UA/SCTP without the need for an upper layer segmentation/re-assembly procedure such as in the ITU White Book SCCP [6] or ISUP segmentation procedures. However, in the context of an SG the maximum 256 octet block size must be followed when interworking to an SS7 network that does not support the transfer of larger blocks to the final destination. This will avoid ISUP or SCCP fragmentation at the SG. However,if the SS7 network supports the Broadband MTP [7] the block size limit can be increased past 256 octets. In the future, M3UA/SCTP could be specified for use between two IP Nodes directly to carry larger ISUP+ (BICC) [8] or MAP/TCAP [9] messages. Provision is made for a seamless, or as seamless as possible, operation of the MTP3-User peers in the SS7 and IP domains. This includes: - Providing an indication to MTP3-Users at an ASP that a remote MTP3-User peer in the SS7 network is not reachable, as expected by all MTP3-User protocols. - Providing an indication to MTP-Users at an ASP that a remote MTP3- User peer in the SS7 network is now reachable, as expected by all MTP3- User protocols. - 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 or the remote MTP3-User peer is unavailable, as expected by all MTP3-User protocols. 1.4.2 Support for communication between Layer Management Modules on the SG and ASP An M-ERROR primitive is used to indicate an error with a received M3UA message (e.g., unknown parameter value). ********* Ed Note: This section is ffs ********* 1.4.3 Support for management of SCTP associations and ASP Paths between the SG and ASP The M3UA layer at the SG keeps the state of all configured ASPs. A set 7 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 of primitives between the Layer Management and the M3UA layer are defined below for the layer Management to manage the ASP Paths and the traffic between the SG and the ASPs. The M3UA layer can be instructed by the Layer 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 to a peer M3UA node. The M3UA layer may also need to inform Layer Management of the status of the underlying SCTP associations using the M-SCTP STATUS request and indication primitive. For example, the M3UA may inform Layer 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. Layer Management may inform the M3UA layer of a change in the local M3UA User status (e.g., failure, available). Also the M3UA layer may need to inform the Layer Management of the change in status of an ASP or ASP Path. This can be achieved using the M-ASP STATUS primitive to change and indicate the status of an ASP. *** Ed Note: This will be moved to a procedures section***** The M3UA layer may be informed of a local M3UA-User failure by means of an indication from local Layer Management. In response, a peer protocol is invoked with the remote M3UA layer to stop traffic over the SCTP association until recovery of the local M3UA-Users. When the M3UA-User layer recovers, local Layer Management informs the M3UA layer and a message is sent to the remote M3UA layer indicating traffic can be restarted over the SCTP association. The M3UA layer maintains status of the local M3UA-User availability. *********************************************** 1.5 Internal Functions Provided in the M3UA Layer 1.5.1 Address Translation and Mapping The M3UA layer maps primitives received from the ASP-User lower layer boundary, or SG nodal interworking function, to the SCTP reliable transport upper layer boundary and maps signals received from the SCTP to the ASP MTP3-User lower layer boundary, or SG nodal interworking function. For example, the MTP-TRANSFER request primitive received from an MTP3-User is mapped to an SCTP Send primitive and the SCTP Receive primitive is mapped to an MTP-TRANSFER indication primitive to the MTP3-User. To support this mapping, the M3UA layer at the SG must additionally maintain a network address translation table of incoming SS7 address/routing information keys to Application Servers. The Application Server represents an ordered list of one or more possible Application Server Processes. Normally, one of the ASPs in the ordered list will be the active ASP for a particular routing key entry. Note that in certain failure and transition cases it is possible that there may not be an active ASP. 8 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 This table is required in order to route the SS7 ISUP/SCCP messages incoming from the SS7 network domain to the appropriate ASP in the IP network domain. This mapping is dynamic, taking into account the availability status of the individual ASP Paths in the list, configuration changes, and possible fail-over mechanisms. Possible SS7 address/routing information to be considered as a routing key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or SCCP Called Party Address. The network address translation function in effect defines the SS7 address representation of the Application Servers within the IP domain. As such, the implementation of this function must be flexible enough to handle the SS7 address vision of network operator(s). For example, some network operators may choose to represent the SG and Application Servers with a single SS7 point code. Other operators may choose to represent each SG and Application Server with individual SS7 point codes, or may group logical groups of Application Servers under point codes. From the perspective of the M3UA instance at an Application Server Process, 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 a 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 loadsharing case is possible where the signaling messages are load- shared across two (or more) SGs. 1.5.2 SCTP Stream Mapping. M3UA also supports the assignment of traffic into streams within an SCTP association. Traffic that requires sequencing should be assigned to the same stream. For example, SS7 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. Traffic that does not require sequencing can be assigned to an unsequenced stream. 1.5.3 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 Application Server 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. Congestion Control mechanisms are for further study. 9 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 1.5.4 Seamless Network Management Interworking. (Ed. Note: It is ffs if this function is modeled in the M3UA layer at an SG or is part of an independent relay function at the SG that is a user of the M3UA layer and MTP-3 layer.) The SG must maintain knowledge of SS7 node and Application Server Cluster status in their respective domains in order to perform as seamless as possible interworking of the two domains. For example, SG knowledge of the availability and/or congestion status of Application Server Clusters and SS7 nodes must be maintained and disseminated in the respective networks so that end-to-end operation is transparent to the communicating SCN protocol peers at the SS7 node and ASP. When an SG determines that the transport of SS7 messages to an Application Server Cluster is encountering congestion, the SG may optionally issue MTP Transfer Controlled (TFC) messages to the SS7 SEPs which are generating signalling traffic to the affected Application Server Cluster, as per current MTP procedures [2]. When an SG determines that the transport of SS7 messages to an Application Server Cluster is interrupted, the SG may optionally issue MTP Transfer Prohibited (TFP) messages to the adjacent SS7 nodes which are generating signalling traffic to the affected Application Server Clusters per current MTP procedures [2]. When an SG determines that the transport of SS7 messages to an Application Server Cluster can now be resumed, the SG may optionally issue MTP Transfer Allowed (TFA) messages to the adjacent SS7 nodes to resume signalling traffic to the affected Application Server Clusters per current MTP procedures [2]. Triggering of the MTP-3 management messages is an implementation dependent function. 1.5.5 Management Inhibit/Uninhibit Local Management 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 manage the start of traffic on to a newly-available SCTP association. 1.5.6 Active Association Control An Application Server Process can have associated back-up process. When, for example, both a primary and a back-up ASP are available, then peer protocol is required to control which ASP, and hence ASP Path, is currently active. The ordered list of ASPs related to an Application Server is kept updated to reflect the active Application Server Process instance. 10 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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 [5] 1.6.3 Definition of the Boundary between M3UA and the Layer Management M-SCTP ESTABLISH M-SCTP RELEASE M-SCTP STATUS M-ASP STATUS M-ERROR (Ed Note: more text to be added) 2.0 Protocol Elements The general message format includes a Common Message Header together with a list of zero or more parameters as defined by the Message Type. For forward compatability, 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 7 8 15 16 31 +-------+-------+---------------+ | Vers | Spare | Msg Type | +-------+-------+---------------+ | Message Length | +---------------+---------------+ 2.1.1 M3UA Protocol Version The version field (vers) contains the version of the M3UA adaptation 11 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 layer. The supported versions are: 01 Release 1.0 protocol 2.1.2 Message Types The following list contains the message types for the defined messages. ISUP/SCCP Tunneling (ITUN) Messages Data Message 0101 SS7 Signalling 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 ITUN Messages The following section describes the ITUN messages and parameter contents. The general ITUN 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, normally including the complete MTP3 Routing Label. The Data message contains the following parameters: SCN PROTOCOL IDENTIFIER (Optional) INTERFACE IDENTIFIER (Optional) PROTOCOL DATA 12 Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999 The format for the Data Message parameters is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | SCN Protocol Identifier* | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Interface Identifier* | +-------------------------------+ | Tag (0xx) | Length | +---------------+---------------+ ... | Protocol Data | ... +---------------+---------------+ The SCN Protocol Identifier parameter identifies explicitly the SCN signaling protocol being transported, where the SCN protocol carried is not known implicitly in the context of a particular association or stream. The SCN Protocol Id defines the protocol type, variant, and version, and thereby specifies the components and encoding of the Protocol Data parameter. The SCN Protocol Id may also define what SCN Protocol Data components are omitted in the Protocol Data (e.g., whether or not the Protocol Data contains an MTP routing label). SCN Protocol Ids will be maintained by IANA outside of this document and may be registered on an "as needed" basis. The SCN 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 SCN Protocol Identifier parameter format is for further study. The protocol identifier values should be maintained outside of this document by IANA to allow registration of values without re- issuing the adaptation layer protocol document. We need decision on encoding of mime-type value or fixed string/integer. If mime-type need to refer to "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP media type defined according to the rules defined in RFC 2048. ************ The Interface Identifier optionally identifies the physical interface, or network, at the SG for which the signaling messages are sent/received. The format is an ASCII string, the values of which are assigned according to network operator policy. The interface Identifier string should be padded to 32-bit boundaries. 13 Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999 ************** Ed Note: The identification of the interface can be very useful at MGCs that are receiving signaling from multiple national networks and cannot rely on the SS7 NI value to tell their signalling traffic apart. However, no procedures are specified. ************** The Protocol Data field contains the MTP3-User application message, which is an MTP-TRANSFER primitive. As defined for a specific value of the Protocol Identifier, this will include the MTP-User Data and normally includes the MTP Routing Label (SS7 OPC, DPC, SLS), and the SIO (Network Indicator & optional Message Priority codes). 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 the ASP to indicate that the SG has determined that an SS7 destination is unreachable. The MTP- 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) Affected Destination Point Code Info String (Optional) The format for DUNA parameter is as follows: 0 7 8 15 16 31 +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Affected DPC | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | INFO String* | +-------------------------------+ The Protocol Identifier parameter is defined similarly to the SCN 14 Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999 Protocol Id 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 size (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 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 can 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 the ASP 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) Affected Destination Point Code Info String (Optional) The parameter format and definitions for the DAVA message is the same as for the DUNA message (See Section 2.3.2.2). 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 is 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 interruption of the transport path to the SG. Protocol Identifier (Optional) Affected Destination Point Code Info String (Optional) The format and description of DAUD parameters is the same as for the DUVA message (See Section 2.3.2.1.) *********** Ed Note: It is for further study whether multiple Affected Destination Point Codes can be included as a list in one DAUD message and in responding DUVA messages. *********** 15 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 The SG receiving the DAUD should reply with the availability state of the queried destination in a DUNA or DAVA message. 2.3.2.4 SS7 Network Congestion (SCON) The SCON message can be sent from the SG to the ASP 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) Affected Destination Point Code Info String (Optional) Congestion Level (Optional) 0 7 8 15 16 31 +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Affected DPC | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | INFO String* | +-------------------------------+ | Tag (0xx) | Length | +---------------+---------------+ | Congestion Level* | +-------------------------------+ The format and description of the Protocol Identifier, Affected DPC and Info String parameters is the same as for the DUVA message (See Section 2.3.2.1.) The valid values for the optional Congestion Level are shown in the following table. 16 Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999 Define Value Description Level 0 0000 No Congestion or Undefined Level 1 0001 Congestion Level 1 Level 2 0002 Congestion Level 2 Level 3 0003 Congestion Level 3 The congestion levels are as defined in the national congestion method in the ITU MTP recommendation [2] or in the ANSI MTP standard [10]. For MTPs without congestion levels, for example the ITU international method, the parameter is omitted. The ASP receiving the SCON message is expected to follow the currently defined MTP3-User protocol reaction to an indication of SS7 network congestion. 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) Affected Destination Point Code Info String (Optional) Reason The format for optional DUPU message is as follows: 0 7 8 15 16 31 +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | Affected DPC | +---------------+---------------+ | Tag (0xx) | Length | +---------------+---------------+ | INFO String* | +-------------------------------+ | Tag (0xx) | Length | +---------------+---------------+ | Reason | +-------------------------------+ 17 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 The format and description of the Protocol Identifier, Affected DPC and Info String parameters is the same as for the DUVA message (See Section 2.3.2.1.) The valid values for Reason are shown in the following table. Define Value Description UPU-Unknown 0x4 MTP User Part Unavailable, No Reason Given UPU-Unequipped 0x5 MTP User Part Unavailable, Unequipped UPU-Inaccessible 0x6 MTP User Part Unavailable, Inaccessible The ASP receiving the DUPU message is expected to follow the currently defined MTP3-User protocol reaction to an indication of remote user part unavailabilty. 2.3.3 Application Server Process Maintenance (ASPM) Messages 2.3.3.1 ASP Up (ASPUP) The ASP-UP 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) SCN Protocol Identifier (optional) INFO String (optional) The format for the ASPUP message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x2) | Length | +---------------+---------------+ | Adaptation Layer Identifier* | +---------------+---------------+ | Tag (0x3) | Length | +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String* | +---------------+---------------+ 18 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 The format and description of the optional Protocol Identifier and Info String parameters is the same as for the DUVA message (See Section 2.3.2.1.) The optional Adaptation Layer Identifier 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-DN 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: INFO String (Optional) The format for the ASPDN message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String* | +---------------+---------------+ **************** Ed Note: Need to add a reason code parameter. Reasons could be failure or 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 the active ASP to be used from within a list of primary and back-up ASPs for a particular AS. The ASPAC message contains the following parameters: INFO String (Optional) The format for the ASPAC message is as follows: 19 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 0 15 16 31 +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String* | +---------------+---------------+ 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 the the active ASP to be used from within a list of primary and back-up ASP for a particular AS. The SG will respond with an ASPIA message and either discard incoming messages or buffer for a timed period and then discard. The ASPIA message contains the following parameters: INFO String (Optional) The format for the ASPIA message is as follows: 0 15 16 31 +---------------+---------------+ | Tag (0x4) | Length | +---------------+---------------+ | INFO String* | +---------------+---------------+ 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 7 8 15 16 31 +---------------+---------------+ | Error Code | +---------------+---------------+ 20 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 The Error Code can be one of the following values: Invalid Version 0x1 Invalid Interface Identifier 0x2 Invalid SCN Version 0x3 Invalid Adaptation Layer Identifier 0x4 Invalid Stream Identifier 0x5 Invalid Message Type 0x6 3.0 Procedures 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 M3UA services 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 a primitive from the upper layer, the M3UA layer will send the corresponding ITUN or SSNM message (see Section 2) to its peer. The M3UA layer must fill in various fields of the common and specific headers correctly. In addition the message needs to be sent on the appropriate SCTP stream. 3.1.2 Receipt of ITUN or SSNM Messages from the Peer M3UA On receiving ITUN or SSNM messages from the remote M3UA Peer, the M3UA layer invokes the appropriate primitive indications to the M3UA-User 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 the local layer management. 3.3 Procedures to support the M3UA services in Section 1.4.3 21 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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 well as the state of the related ASs. 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. At most one ASP per AS can be in the active state. 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 | +-------------+ 22 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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. AS-PENDING: The Active ASP has transitioned from active to inactive or down. 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. 23 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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". 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 24 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 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 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 MGC even if that path was already marked as UP at the SG. The paths are controlled by the MGC. The SG will only send ASPUP in response to the reception of a ASPUP message. The MGC will send ASPUP messages every 2 (add text regarding this being a configurable timer) seconds until the path comes up (i.e. until it receives a ASPUP message from the SG for that path). The MGC may decide to reduce the frequency (say to every 5 seconds) if the an acknowledge- ment is not received after a few tries. The MGC should wait for the ASPUP message from the SG before transmitting ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will risk message loss. The ASPUP message received from the SG is not acknowledged by the MGC. 3.3.3.2 ASP Down The SG will mark the ASP as down and send a ASPDN message to the MGC if one of the following events occur: - a ASP Down(ASPDN) message is received from the MGC, - the ASP is locked by local maintenance. The SG will also send a ASPDN message when the ASP is already down and a ASPDN) message is received from the MGC. The MGC 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 25 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 (for example, during a MGC node failover), 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 a 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 are, by default, down. 4.0 Examples of M3UA Procedures 4.1 Establishment of associations between an SG and an ASP An example of the message flows for establishing an active association between an SG and ASP is shown below. SG ASP1 <----------- ASP Up ASP Up ----------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) An example of message flows for establishment of associations with two ASPs and the message flows for take-over of the primary (ASP1) by the secondary (ASP2). 26 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 SG ASP1 ASP2 <----------- ASP Up ASP Up ----------> (ACK) <------------------------------ ASP Up ASP Up ------------------------------> (ACK) <----------- ASP Active ASP Active ----------> (ACK) ... <----------- ASP Inactive ASP Inactive ----------> (ACK) (this message is optional) ASP Inactive ------------------------------> <------------------------------ ASP Active ASP Active ------------------------------> (ACK) 4.2 M3UA/MTP3-User Boundary Examples ***************** Ed Note: Text to be added ***************** 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 for his valuable comments and suggestions. 7.0 References [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling System No. 7 (SS7)' [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' [3] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - 27 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 Service Specific Coordination Function for signaling at the Network Node Interface (SSCF at NNI) [4] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) [5] Simple Control Transport Protocol draft-ietf-sigtran-sctp-00.txt, Sept. 1999, Work in Progress [6] ITU-T Recommendation Q.711-714 'Signalling System No. 7 (SS7) - Signaling Connection Control Part (SCCP)' [7] ITU-T Recommendation Q.2210 'B-ISDN MTP' [8] ITU-T Recommendation Q.xxxx 'ISUP BICC' [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 (SS7) - Transaction Capabilities (TCAP) [10] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' 5.0 Author's Addresses Lyndon Ong Nortel Networks 4401 Great America Pkwy Santa Clara, CA, USA 95054 long@nortelnetworks.com Greg Sidebottom Nortel Networks 3685 Richmond Rd, Nepean, Ontario, Canada K2H 5B7 gregside@nortelnetworks.com Guy Mousseau Nortel Networks 3685 Richmond Rd Nepean, Ontario, Canada K2H 5B7 Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000, Australia ian.rytina@ericsson.com Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 5181359 Munich, Germany HannsJuergen.Schwarzbauer@icn.siemens.de 28 Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999 Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA, USA 20171 EMail: kmorneau@cisco.com Malleswar Kalla Telcordia Technologies MCC 1J211R 445 South Street Morristown, NJ, USA 07960 EMail: kalla@research.telcordia.com This draft expires April 2000. 29