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
<draft-ietf-sigtran-itun-00.txt>
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
Datatracker
Report a datatracker bug
draft-ietf-sigtran-itun-00
None
| Document | Document type |
Expired Internet-Draft
(sigtran WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Lyndon Ong
,
Ian Rytina
,
Greg Sidebottom
,
Dr. HannsJuergen Schwarzbauer
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |