Network Working Group G. Sidebottom, L. Ong INTERNET-DRAFT Nortel Networks Ian Rytina Ericsson Hanns-Juergen Schwarzbauer Siemens Expires in six months 18 June 1999 SS7 ISUP Tunneling 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 tunneling of SS7 signaling over IP using the Sigtran Common Transport Protocol. This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC) 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. 1 Internet Draft SS7 ISUP Tunneling Jun 1999 TABLE OF CONTENTS 1. Introduction..............................................3 2. Protocol Elements.........................................8 3. Procedures...............................................17 4. References...............................................19 5. Author's Addresses.......................................19 2 Internet Draft SS7 ISUP Tunneling Jun 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 SS7 MTP-User Part protocols * Support for the MTP-User service interface * Support for a request/response mechanism to open and close the transport associations between SG and MGC * Support for the asynchronous reporting of any status changes of the signalling channel 1.2 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 functions expected by a particular SCN signaling protocol from its underlying protocol layer. This document defines an adaptation module that is suitable for the transport of SS7 ISDN User Part (ISUP) but could be used equally to transport other SS7 MTP-3 User Parts such as, for example, SCCP (together with its subsystems e.g., INAP/TC and TUP. The figure below shows how the SS7 Gateway Module fits within the Sigtran architecture. +-------------------------------+ | | | SS7 ISUP | +-------------------------------+ | ITUN | | Adaptation Module | |-------------------------------| | Signaling Common Transport | |-------------------------------| | IP Transport | +-------------------------------+ In a Signaling Gateway, it is expected that the SS7 ISUP signaling is received over a standard SS7 network termination, using the SS7 Message Transfer Part (MTP) to provide transport of ISUP signaling messages to and from an SS7 Signaling End Point (SEP). The SG then provides interworking of transport functions with IP Signaling Transport, in order to transport the ISUP signaling messages to the MGC where the peer ISUP protocol layer exists, as shown below: 3 Internet Draft SS7 ISUP Tunneling Jun 1999 ****** SS7 ****** IP ******* *SEP *---------* SG *------------* MGC * ****** ****** ******* +----+ +-----+ |ISUP| | ISUP| +----+ +---------+ +-----+ |MTP | |MTP |ITUN| | ITUN| |L3 | |L3 +----+ +-----+ |L2 | |L2 |SCTP| | SCTP| |L1 | |L1 +----+ +-----+ | | | |U/T | | U/T | +----+ +---------+ +-----+ SEP - SS7 Signaling Endpoint U/T - UDP/TCP SCTP - Signaling Common Transport Protocol (aka MDTP [5]) 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 SSCF/SSCOP [3,4]. Also, STPs may be present in the SS7 path between the SEP and the SG. 1.2 Services Provided by the ITUN Layer The SS7 ISUP/MTP (MTP-User) interface is retained at the termination point in the IP network, so that the ITUN 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 [2]: TRANSFER Providing the ability to transport MTP-User information (in this Case, ISUP PDUs). PAUSE Providing an indication to the MTP-User that the remote MTP-User is not reachable. RESUME Providing an indication to the MTP-User that the remote MTP-User is now reachable. STATUS Providing an indication to the MTP-User that messages to the remote MTP- User are experiencing congestion or other conditions. 5 Internet Draft SS7 ISUP Tunneling Jun 1999 1.3 Functions Provided by the ITUN Layer 1.3.1 Internal Functions a) Mapping. The ITUN layer maps primitives received from the MTP-User Layer (i.e., ISUP) to the SCTP (MDTP) reliable transport upper layer boundary and maps signals received from the SCTP to the MTP-User lower layer boundary. For example, the MTP-Transfer request primitive received from the MTP-User is mapped to an MDTP-Send.Data primitive and the MDTP- Receive.Data primitive is mapped to an MTP-Transfer indication primitive to the MTP-User. The ITUN layer must additionally maintain a current network address mapping table of relevant SS7 address information to SCTP associations/streams. This is required in order to route the SS7 messages incoming from the SS7 network domain to the appropriate MGC in the IP network domain, or to route SS7 messages originated at an MGC to the appropriate SG. This mapping could be dynamic given the availability status of the individual SCTP associations, configuration changes, and possible MGC fail-over mechanisms. Possible SS7 information to be considered includes, for example, the OPC, DPC, SLS and/or ISUP CIC. The mapping function in effect defines the SS7 address representation of the network elements within the IP domain. As such, the implementation of this function must be flexible enough to handle the SS7 numbering plan vision of network operator(s). For example, some network operators may choose to represent a SG/MGC pair as a SS7 SEP with a single point code. Other operators may choose to represent logical groups of MGCs with point codes. >From the perspective of the ITUN instance at the MGC, it is possible that the MGC could route signaling messages destined to SS7 SEPs through more than one SG. A primary/back-up case is possible where the transport unavailability of a primary SG (or routing unavailability of the SS7 SEP 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. b) Flow Control. The ITUN Layer is informed of congestion by means of an implementation- dependent function. Congestion is indicated to local MTP-Users by means of an MTP-Status primitive. c) Reporting to Layer Management. Certain events are reported to Layer management. For example, the ITUN may inform Layer Management of the reason for the release of an SCTP association, determined either locally within the ITUN layer or by a primitive from the SCTP. 5 Internet Draft SS7 ISUP Tunneling Jun 1999 d) Change Link Status The ITUN layer maintains local state variables pertaining to the status of the SCTP transport associations. e) Seamless Network Management Interworking. (Ed. Note: It is ffs if this function is in the ITUN layer at an SG or is part of an independent relay function at the SG that is a user of the ITUN layer and MTP-3 layer.) The SG must maintain knowledge of the SS7 and IP network management status in the respective domains in order to perform as seamless as possible interworking of the two domains. For example, SG knowledge of the transport availability of the MGCs and SS7 SEPs must be maintained and disseminated in the respective networks so that end-to-end operation is transparent to the communicating ISUP peers at the SS7 SEP and the MGC. Where an SG determines that the transport of SS7 messages to an MGC is encountering congestion, the SG may in some cases issue MTP-3 TFC messages to SS7 SEPs which are generating signalling traffic to the affected MGC, as per current MTP procedures [2]. Triggering of the MTP-3 flow control procedure is an implementation dependent function. 1.3.2 Functions with peer-to-peer Messages Some functions performed by the ITUN layer utilize per-to-peer protocol. a) ITUN-User Failure The ITUN layer is informed of a local ITUN-User failure by means of an indication from Layer Management. In response, peer protocol is invoked with the remote ITUN layer to stop traffic in over the SCTP association until recovery of the local ITUN-User. The layer maintains status of the local ITUN-User availability. Also, reception of PDUs from the remote ITUN peer may indicate failure of the remote ITUN-User, causing the function to stop traffic to the remote peer and report an indication of the reason to Layer Management. The ITUN layer at the SG passes this indication to the local MTP-3. b) 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. c) Active Association Control In some cases, an MGC process can have a back-up MGC process. If a primary and secondary instances are available across different SCTP associations, then peer protocol is required to control which process, 6 Internet Draft SS7 ISUP Tunneling Jun 1999 and hence SCTP association, is currently active. The SS7 to IP mapping table is updated to reflect the current MGC process instance currently used. 1.4 Definition of the Upper Layer Boundary between ITUN and ISUP >From ITU Q.701 [2]: MTP-Transfer Request MTP-Transfer Indication MTP-Pause Indication MTP-Resume Indication MTP-Status Indication 1.5 Definition of the Lower Layer Boundary between ITUN and SCTP Note: the upper layer boundary primitives identified here are from the latest issue of the MDTP draft [5]. Note: These primitives are potentially subject to change, as are any related MDTP and ITUN procedures. MDTP-Init.MDTP MDTP-Init.Association MDTP-Term.Association MDTP-Send.Data MDTP-Receive.Data MDTP-Data.Arrive notification MDTP-Send.Failure notification MDTP-Network.Status.Change notification MDTP-Communication.Up notification MDTP-Communication.Lost notification MDTP-Change.Network.Rotation MDTP-Open.Stream MDTP-Close.Stream (Ed. Note: Are some of these primitives actually between SCTP and the Layer Management (e.g., MDTP-Change.Network.Rotation, MDTP- Init.MDTP,...). If so, they should not be defined in this document.) 1.6 Definition of the Boundary between ITUN and the Layer Management (Optional) M-Open request M-Release request M-Local Stop request M-Local Stop confirm M-Remote Stop indication M-Local Resume request M-Remote Resume indication M-Report indication 7 Internet Draft SS7 ISUP Tunneling Jun 1999 2.0 Protocol Elements 2.1 Message Header The messages passed between the SG and the MGC require a message structure which contains the protocol version, a message type, message length and message contents. The message header includes the protocol version, type and length (ed. Note: Protocol ID req'd? Is length necessary?). The valid message types are defined in Section 2.2.2 and the message contents are described in Section 2.3. The general message format is shown in Figure 1. Each message can contain multiple parameters as indicated in Figure 1 0 7 8 15 16 31 +---------------+---------------+ | Vrsn | Spare | Msg Type | +-------------------------------+ | Message Length | +---------------+---------------+ | | Parameter 1 | | +---------------+---------------+ . . . +---------------+---------------+ | | Parameter n | | +---------------+---------------+ Figure 1: Message Format 2.2.1 Protocol Version The supported versions are: 01 Release 1.0 protocol If a message with an unknown protocol version is received, the receiving node will respond to the sender with an Path Version message (see Section 2.3.3.3). This will inform the sender that a message with an unsupported version has been received and will indicate to the sender the supported version. 8 Internet Draft SS7 ISUP Tunneling Jun 1999 2.2.2 Message Types The following list contains the message types for the defined messages. ISUP Tunneling (ITUN) Messages Transfer Message 0101 SS7 Signalling Network Management (SSNM) Messages Destination Unavailable (DUNA) 0201 Destination Available (DAVA) 0202 Destination State Audit (DAUD) 0203 Destination Partially Available (DPAV) 0204 SS7 Network Congestion State (SCON) 0205 Destination User Part Unavailable (DUPU) 0206 IP Transport Path Availability Management (TPAM) Messages Path-up (PTUP) 0301 Path-Down (PTDN) 0302 Path Version (PTVR) 0304 IP Node Maintenance (IPNM) Messages Node Up (NDUP) 0401 Node Down (NDDN) 0402 2.2.3 Message Length The Message length defines the length of the message in octets, not including the header. 2.3 Message Types The following section defines the message types and parameter contents. 2.3.1 ISUP Tunneling (ITUN) Messages 2.3.1.1 Transfer Message The Transfer message contains an SS7 MTP-User Protocol Data Unit (PDU). In addition, it may contain information from the MTP 3 routing label in order to distinguish the interface being controlled. The TRANSFER message contains the following parameters: 9 Internet Draft SS7 ISUP Tunneling Jun 1999 PROTOCOL IDENTIFIER INTERFACE IDENTIFIER PROTOCOL DATA The format for the Transfer Message parameters is as follows: 0 15 16 31 +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ | Interface Identifier | +-------------------------------+ ... | Protocol Data | ... +---------------+---------------+ * The Protocol Identifier format is for further study. The protocol identifier values should be maintained outside of this document to allow addition/deletion of values without re-issuing the adaptation layer protocol document. The Protocol Identifier field contains the identity of the specific SCN signaling protocol being transported. The Protocol ID defines the protocol type, variant, and version, and thereby specifies the components and encoding of the PROTOCOL DATA field. The Protocol Identifier also defines what SCN protocol message components are included in the PROTOCOL DATA (e.g., whether or not the DATA contains the MTP routing label). (Ed. Note: Need encoding of mime-type value or OID or fixed string/integer that will be administered outside of this document (IANA). Also, perhaps bring in text from Christian's mime document - See "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 identifies the physical interface, or network at the SG for which the signaling messages are sent/received. The format is for further study, while the values assigned according to network operator policy. This knowledge 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. The PROTOCOL DATA field contains the MTP-User application message. 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 (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 MGC to indicate that the SG has determined that an SS7 destination is unreachable. The MTP- User at the MGC is expected to stop traffic to the affected destination through the SG initiating the DUNA. 10 Internet Draft SS7 ISUP Tunneling Jun 1999 The DUNA message contains the following parameters: Protocol Identifier INFO STRING AFFECTED Destination Point Code The format for DUNA parameter is as follows: 0 7 8 15 16 31 +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Affected DPC* | +---------------+---------------+ The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. 2.3.2.2 Destination Available (DAVA) The DAVA message can be sent from the SG to the MGC to indicate that the SG has determined that an SS7 destination is now reachable. The MGC ISUP is expected to resume traffic to the affected destination through the SG initiating the DUNA. The DAVA message contains the following parameters: Protocol Identifier INFO String AFFECTED Destination Point Code 11 Internet Draft SS7 ISUP Tunneling Jun 1999 The format for DAVA parameter is the same as for the DUNA message (See Section 2.3.2.1.) The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. This knowledge 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. 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. 2.3.2.3 Destination State Audit (DAUD) The DAUD message can be sent from the MGC to the SG to query the availability state of the route to an affected destination state is unavailable or stale (e.g., the transport path to the SG has been interrupted) Protocol Identifier INFO String Affected Destination Point Code The format for DAUD parameter is the same as for the DUVA message (See Section 2.3.2.1. It is for further study whether multiple Affected Destination Point Codes can be included in one DAUD message. The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. This knowledge 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. 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. 12 Internet Draft SS7 ISUP Tunneling Jun 1999 The SG receiving the DAUD should reply with the availability state of the queried destination in a DUNA,DAVA, or DPAV message. 2.3.2.4 Destination Partially Available (DPAV) - Optional The Optional DPAV message can be sent from the SG to the MGC to indicate that the SG is using a secondary route to the destination. The DPAV message contains the following parameters: Protocol Identifier INFO String Affected Destination Point Code The format for DPAV parameter is the same as for the DUVA message (See Section 2.3.2.1). The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. This knowledge 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. 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. The MGC receiving the DPAV should, if possible, re-route the affected signalling traffic to an alternate SG, assuming the alternate SG is still using its normal route. 2.3.2.5 SS7 Network Congestion (SCON) The SCON message can be sent from the SG to the MGC 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 INFO String AFFECTED Destination Point Code CONGESTION LEVEL The format for optional CONGESTION parameter is as follows: 13 Internet Draft SS7 ISUP Tunneling Jun 1999 0 7 8 15 16 31 +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Affected DPC* | +---------------+---------------+ | Congestion Level | +-------------------------------+ The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. This knowledge 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. 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. The valid values for CONGESTION LEVEL are shown in the following table. 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 MGC receiving the SCON message is expected to follow the currently defined MTP-User protocol reaction to an indication of network congestion. 2.3.2.6 Destination User Part Unavailable (DUPU) The DUPU message is used by a SG to inform an MGC that a remote peer ISUP User Part at an SS7 node is unavailable. 14 Internet Draft SS7 ISUP Tunneling Jun 1999 The DUPU message contains the following parameters: Protocol Identifier INFO String AFFECTED Destination Point Code Reason The format for optional DUPU is as follows: 0 7 8 15 16 31 +---------------+---------------+ | Protocol Identifier* | +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Affected DPC* | +---------------+---------------+ | Reason | +-------------------------------+ The Protocol Identifier parameter (see Section 2.3.1.1) is used here to determine the format of the Affected DPC parameter and User Part. By identifying the protocol type, variant, and version, the point code size (e.g., 14- 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. This knowledge 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. 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. If an INFO String is not included, a length of "0" is used. The Affected DPC is provisionally a three-octet parameter to allow 14- and 24-bit SS7 formatted SS7 Point Codes. 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 15 Internet Draft SS7 ISUP Tunneling Jun 1999 The MGC receiving the DUPU message is expected to follow the currently defined MTP-User protocol reaction to an indication of remote user part unavailabilty. 2.3.3 IP Transport Path Availability Management (TPAM) Messages 2.3.3.1 Path-up (PTUP) The PTUP message is used to indicate to a remote ITUN peer that the layer is ready to receive traffic or maintenance messages The PTUP message contains the following parameters: INFO String The format for the PTUP message is as follows: 0 7 8 15 16 31 +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Spare | +---------------+---------------+ 2.3.3.2 Path-Down (PTDN) The PTDN message is used to indicate to a remote ITUN peer that the layer is not ready to receive traffic or maintenance messages. The PTDN message contains the following parameters: INFO String The format for the PTDN message is as follows: 0 7 8 15 16 31 +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Spare | +---------------+---------------+ 2.3.3.3 Path Version (PTVR) The PTVR message is used in response to a PTUP or PTDN message to indicate that the indicated version is not supported. The message header of the PTVR will indicate the version supported. The PTVR message contains the following parameters: INFO String The format for the PTVR message is as follows: 0 7 8 15 16 31 +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Spare | +---------------+---------------+ 2.3.4 IP Node Maintenance (IPNM) Messages 2.3.4.1 Node Up (NDUP) The NDUP message is sent by an MGC to indicate to an SG that it is the active MGC to be used from within a list of primary and back-up MGCs for a particular signalling mapping relationship. The NDUP message contains the following parameters: INFO String The format for the NDUP message is as follows: 0 7 8 15 16 31 +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Spare | +---------------+---------------+ 2.3.4.2 Node Down (NDDN) The NDDN message is sent by an MGC to indicate to an SG that it is no longer the the active MGC to be used from within a list of primary and back-up MGCs for a particular signalling mapping relationship. The SG will respond with an NDDN message and either buffer or discard incoming messages for a timed period and then discard. The NDUP message contains the following parameters: INFO String The format for the NDUP message is as follows: 0 7 8 15 16 31 +---------------+---------------+ |Length | INFO String | . . . + +-------+---------------+ | | Spare | +---------------+---------------+ 3.0 Procedures 3.1 IP Transport Path Availability Management (TPAM) Procedures 3.1.1 Path State The possible states of a path are: Down: Path down. Up: Path up. The transport association is active and node maintenance messages can be exchanged when the path is up. Active: MTP-User PDUs can be carried over the path. 3.1.2 Path up 3.1.2.1 SG Operation The SG will mark the path as up if an explicit path-up (PTUP) message is received and internally the path is allowed to come up (i.e., not in a locked local maintenance state). A path-up (PTUP) message will be sent to acknowledge the received PTUP. The SG will respond to a PTUP with a PTDN message if the path is in a locked maintenance state. The SG will send a PTUP message in response to a received PTUP 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 PTUP in response to the reception of a PTUP message. 3.1.2.2 MGC Operation The MGC will send PTUP messages every 2 seconds until the path comes up (i.e. until it receives a PTUP message from the SG for that path). The MGC may decide to reduce the frequency (say to every 5 seconds) if the path does not come up after a few tries. The MGC should wait for the PTUP message from the SG before transmitting Node maintenance messages (NDDN or NDUP) or ITUN messages or it will risk message loss. The PTUP message received from the SG is not acknowledged by the MGC. The PTUP messages will be sent by the MGC until the path comes up or until the paths are manually locked on the MGC side. 3.1.3 Path Down 3.1.3.1 SG Operation The SG will mark the path as down and send a PTDN message to the SS if one of the following events occur: - a Path-down (PTDN) message is received from the MGC, - the path is locked by local maintenance. The SG will also send a PTDN message when the path is already down and a PTDN) message is received from the MGC. 3.1.3.2 MGC Operation The MGC will send PTDN whenever it wants to take down a path. Since the PTDN messages to the SG or the PTDN responses from the SG can be lost, the MGC can send PTDN messages every 2 seconds until the path comes down (i.e. until it receives a PTDN message from the SG for that path). 3.1.4 Path Version Control If a message with an unknown version is received, the receiving node will respond with a path version (PTVR) 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 PTVR message header associated with the will indicate the version supported by the node. 3.2 IP Node Maintenance (IPNM) Messages 3.2.1 Node State Two MGC states are possible: Node down and Node up. NDDN and NDUP messages are sent by the MGC to the SG, which will acknowledge by returning an NDDN or NDUP message. These messages are only accepted by a node if the path the message is received on is up. If the path is down the SG will respond to either message with a PTDN message. Only one MGC from a list of primary and back-up MGCs (for a particular signalling mapping relationship) can be active at any one time. Reception of a NDUP will cause the other MGCs in the list to be forced down. 3.2.2 Node Down When a NDDN message is received, message transmission to that MGC ceases. The SG will either discard all incoming messages or start buffering the incoming messages for b seconds after which messages will be discarded. 3.2.3 Node Up When a node up (NDUP) message is received, the SG will start routing to that MGC. Reception of a NDUP message overrides any previous NDUP messages and results in the MGC associated with the NDUP message to become the newly active MGC. 4.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 - 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] Multi-Network Datagram Transmission Protocol draft-ietf-sigtran-mdtp-06.txt, June 1999 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 K2H5B7 gregside@nortelnetworks.com Ian Rytina Ericsson Australia 37/360 Elizabeth StreetMelbourne, Victoria 3000, Australiaian.rytina@ericsson.com Hanns Juergen Schwarzbauer SIEMENS AGHofmannstr. 5181359 Munich, GermanyHannsJuergen.Schwarzbauer@icn.siemens.de