draft-ietf-sigtran-rfc3332bis-04.txt   draft-ietf-sigtran-rfc3332bis-05.txt 
Network Working Group K. Morneault Network Working Group K. Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Expires: December 2005 Expires: March 2006
J. Pastor-Balbas J. Pastor-Balbas
Ericsson Ericsson
June 2005 Oct 2005
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA) User Adaptation Layer (M3UA)
<draft-ietf-sigtran-rfc3332bis-04.txt> <draft-ietf-sigtran-rfc3332bis-05.txt>
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire November 2005. This Internet-Draft will expire March 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This memo defines a protocol for supporting the transport of any SS7 This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol. Also, services of the Stream Control Transmission Protocol. Also,
skipping to change at page 7, line 16 skipping to change at page 7, line 16
parameter values that uniquely define the range of signalling traffic parameter values that uniquely define the range of signalling traffic
to be handled by a particular Application Server. Parameters within to be handled by a particular Application Server. Parameters within
the Routing Key cannot extend across more than a single Signalling the Routing Key cannot extend across more than a single Signalling
Point Management Cluster. Point Management Cluster.
Routing Context - A value that uniquely identifies a Routing Key. Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration Routing Context values are either configured using a configuration
management interface, or by using the routing key management management interface, or by using the routing key management
procedures defined in this document. procedures defined in this document.
Signaling End Point (SEP) - A node in the SS7 network associated with
an originating or terminating local exchange (switch) or a gateway
exchange.
Signalling Gateway Process (SGP) - A process instance of a Signalling Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, backup, load-sharing or broadcast Gateway. It serves as an active, backup, load-sharing or broadcast
process of a Signalling Gateway. process of a Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends Signalling Gateway (SG) - An SG is a signaling agent that receives/
SCN native signaling at the edge of the IP network [11]. An SG sends SCN native signaling at the edge of the IP network [11]. An SG
appears to the SS7 network as an SS7 Signalling Point. An SG appears to the SS7 network as an SS7 Signalling Point. An SG
contains a set of one or more unique Signalling Gateway Processes, of contains a set of one or more unique Signalling Gateway Processes, of
which one or more is normally actively processing traffic. Where an which one or more is normally actively processing traffic. Where an
SG contains more than one SGP, the SG is a logical entity and the SG contains more than one SGP, the SG is a logical entity and the
contained SGPs are assumed to be coordinated into a single management contained SGPs are assumed to be coordinated into a single management
view to the SS7 network and to the supported Application Servers. view to the SS7 network and to the supported Application Servers.
Signalling Process - A process instance that uses M3UA to communicate Signalling Process - A process instance that uses M3UA to communicate
with other signalling processes. An ASP, an SGP and an IPSP are all with other signalling processes. An ASP, an SGP and an IPSP are all
signalling processes. signalling processes.
skipping to change at page 7, line 44 skipping to change at page 7, line 48
Application Servers represented to the SS7 network under a single MTP Application Servers represented to the SS7 network under a single MTP
entity (Signalling Point) in one specific Network Appearance. SPMCs entity (Signalling Point) in one specific Network Appearance. SPMCs
are used to aggregate the availability, congestion, and user part are used to aggregate the availability, congestion, and user part
status of an MTP entity (Signalling Point) that is distributed in the status of an MTP entity (Signalling Point) that is distributed in the
IP domain, for the purpose of supporting MTP3 management procedures IP domain, for the purpose of supporting MTP3 management procedures
towards the SS7 network. In some cases, the SG itself may also be a towards the SS7 network. In some cases, the SG itself may also be a
member of the SPMC. In this case, the SG availability /congestion member of the SPMC. In this case, the SG availability /congestion
/User_Part status should also be taken into account when considering /User_Part status should also be taken into account when considering
any supporting MTP3 management actions. any supporting MTP3 management actions.
Signaling Transfer Point (STP) - A node in the SS7 network that
provides network access and performs message routing, screening and
transfer of of signaling messages.
Stream - A stream refers to an SCTP stream; a unidirectional logical Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service. except for those submitted to the unordered delivery service.
1.3 M3UA Overview 1.3 M3UA Overview
1.3.1 Protocol Architecture 1.3.1 Protocol Architecture
The framework architecture that has been defined for SCN signalling The framework architecture that has been defined for SCN signalling
skipping to change at page 17, line 7 skipping to change at page 17, line 7
optionally be used to control the start of traffic on to a newly optionally be used to control the start of traffic on to a newly
available SCTP association. available SCTP association.
1.4.6 Congestion Management 1.4.6 Congestion Management
The M3UA layer is informed of local and IP network congestion by The M3UA layer is informed of local and IP network congestion by
means of an implementation-dependent function (e.g., an means of an implementation-dependent function (e.g., an
implementation dependent indication from the SCTP of IP network implementation dependent indication from the SCTP of IP network
congestion). congestion).
At an ASP or IPSP, the M3UA layer indicates congestion to local At an ASP or IPSP, the M3UA layer indicates IP network congestion to
MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3 local MTP3-Users by means of an MTP-STATUS primitive, as per current
procedures, to invoke appropriate upper layer responses. MTP3 procedures, to invoke appropriate upper layer responses.
When an SG determines that the transport of SS7 messages to a When an SG determines that the transport of SS7 messages to a
Signalling Point Management Cluster (SPMC) is encountering Signalling Point Management Cluster (SPMC) is encountering
congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled IP network congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled
management messages to originating SS7 nodes, per the congestion management messages to originating SS7 nodes, per the congestion
procedures of the relevant MTP3 standard. The triggering of SS7 MTP3 procedures of the relevant MTP3 standard. The triggering of SS7 MTP3
Management messages from an SG is an implementation-dependent Management messages from an SG is an implementation-dependent
function. function.
The M3UA layer at an ASP or IPSP MAY indicate local congestion to an The M3UA layer at an ASP or IPSP MAY indicate local congestion to an
M3UA peer with an SCON message. When an SG receives a congestion M3UA peer with an SCON message. When an SG receives a congestion
message (SCON) from an ASP, and the SG determines that an SPMC is now message (SCON) from an ASP, and the SG determines that an SPMC is now
encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled
management messages to concerned SS7 destinations according to management messages to concerned SS7 destinations according to
congestion procedures of the relevant MTP3 standard. congestion procedures of the relevant MTP3 standard.
1.4.7 SCTP Stream Mapping. 1.4.7 SCTP Stream Mapping
The M3UA layer at both the SGP and ASP also supports the assignment The M3UA layer at both the SGP and ASP also supports the assignment
of signalling traffic into streams within an SCTP association. of signalling traffic into streams within an SCTP association.
Traffic that requires sequencing SHOULD be assigned to the same Traffic that requires sequencing SHOULD be assigned to the same
stream. To accomplish this, MTP3-User traffic may be assigned to stream. To accomplish this, MTP3-User traffic may be assigned to
individual streams based on, for example, the SLS value in the MTP3 individual streams based on, for example, the SLS value in the MTP3
Routing Label, subject of course to the maximum number of streams Routing Label, subject of course to the maximum number of streams
supported by the underlying SCTP association. supported by the underlying SCTP association.
The following rules apply (see section 3.1.2): The following rules apply (see section 3.1.2):
skipping to change at page 20, line 51 skipping to change at page 20, line 51
interworking function has no visible peer protocol with either the interworking function has no visible peer protocol with either the
ASP or SEP. ASP or SEP.
Note that the services and interface provided by the M3UA layer are Note that the services and interface provided by the M3UA layer are
the same as in Example 1 and the functions taking place in the SCCP the same as in Example 1 and the functions taking place in the SCCP
entity are transparent to the M3UA layer. The SCCP protocol entity are transparent to the M3UA layer. The SCCP protocol
functions are not reproduced in the M3UA protocol. functions are not reproduced in the M3UA protocol.
1.6 Definition of M3UA Boundaries 1.6 Definition of M3UA Boundaries
This section provides a definition of the boundaries of the M3UA
protoccol. They consist of SCTP, Layer Management and the MTP3-User.
+-----------+
| MTP3-User |
+-----------+
|
|
+-----------+ +------------+
| M3UA |-----| Layer Mgmt |
+-----------+ +------------+
|
|
+-----------+
| SCTP |
+-----------+
1.6.1 Definition of the Boundary between M3UA and an MTP3-User. 1.6.1 Definition of the Boundary between M3UA and an MTP3-User.
From ITU Q.701 [7]: From ITU Q.701 [7]:
MTP-TRANSFER request MTP-TRANSFER request
MTP-TRANSFER indication MTP-TRANSFER indication
MTP-PAUSE indication MTP-PAUSE indication
MTP-RESUME indication MTP-RESUME indication
MTP-STATUS indication MTP-STATUS indication
skipping to change at page 29, line 15 skipping to change at page 29, line 15
Reserved 0x020f Reserved 0x020f
Protocol Data 0x0210 Protocol Data 0x0210
Reserved 0x0211 Reserved 0x0211
Registration Status 0x0212 Registration Status 0x0212
Deregistration Status 0x0213 Deregistration Status 0x0213
Reserved by the IETF 0x0214 to 0xffff Reserved by the IETF 0x0214 to 0xffff
The value of 65535 is reserved for IETF-defined extensions. The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific parameter description Values other than those defined in specific parameter description
are reserved for use by the IETF. are reserved for use by the IETF. A RFC is required to make use
of parameter values "Reserved by the IETF".
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter The Parameter Length field contains the size of the parameter
in bytes, including the Parameter Tag, Parameter Length, and in bytes, including the Parameter Tag, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes. If the Parameter Length does not include any padding bytes. If the
parameter contains subparameters, the Parameter Length field parameter contains subparameters, the Parameter Length field
will include all the bytes of each subparameter including will include all the bytes of each subparameter including
 End of changes. 13 change blocks. 
18 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/