draft-ietf-sigtran-m2ua-01.txt   draft-ietf-sigtran-m2ua-02.txt 
Network Working Group Ken Morneault Network Working Group Ken Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Ram Dantu Ram Dantu
Tom George
Alcatel Alcatel
Expires in six months October 1999 Expires in six months December 1999
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-01.txt> <draft-ietf-sigtran-m2ua-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5. Security.................................................31 5. Security.................................................31
6. Acknowledgements.........................................31 6. Acknowledgements.........................................31
7. References...............................................31 7. References...............................................31
8. Author's Addresses.......................................32 8. Author's Addresses.......................................32
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for SCN signaling protocol delivery from an Signaling There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to a Media Gateway Controller (MGC) or Signaling Control Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point
Point (SCP). The delivery mechanism should meet the following criteria: (IPSP). The delivery mechanism should meet the following criteria:
* Support for MTP Level 2 / MTP Level 3 interface boundary * Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG and * Support for communication between Layer Management modules on SG and
MGC MGC
* Support for management of active associations between the SG and MGC * Support for management of active associations between the SG and MGC
In other words, the Signaling Gateway will transport MTP Level 3 messages In other words, the Signaling Gateway will transport MTP Level 3 messages
to a Media Gateway Controller (MGC) or Signaling Control Point (SCP). to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). In the
case of delivery from an SG to an IPSP, the SG and IPSP function as
traditional SS7 nodes using the IP network as a new type of SS7 link.
This allows for full MTP Level 3 message handling and network management
capabilities.
1.2 Terminology 1.2 Terminology
MTP2-User - A protocol that normally uses the services of MTP Level 2 MTP2-User - A protocol that normally uses the services of MTP Level 2
(i.e. MTP3). (i.e. MTP3).
Interface - For the purposes of this document, an interface is a SS7 Interface - For the purposes of this document, an interface is a SS7
signaling link. signaling link.
Association - An association refers to a SCTP association. The Association - An association refers to a SCTP association. The
association will provide the transport for the delivery of protocol association will provide the transport for the delivery of protocol
data units for one or more interfaces. data units for one or more interfaces.
Stream - A stream refers to a SCTP stream. For the purposes of this Stream - A stream refers to a SCTP stream.
document, a stream will be mapped to a SS7 signaling link, or interface.
Backhaul - Refers to the transport of signaling from the point of Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU) interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not back to the point of call processing (i.e., the MGCU), if this is not
local [4]. local [4].
Application Server (AS) - A logical entity serving a specific application Application Server (AS) - A logical entity serving a specific application
instance. An example of an Application Server is a MGC handling the instance. An example of an Application Server is a MGC handling the
MTP Level 3 and call processing for SS7 links terminated by the Signaling MTP Level 3 and call processing for SS7 links terminated by the Signaling
Gateways. Practically speaking, an AS is modeled at the SG as an ordered Gateways. Practically speaking, an AS is modeled at the SG as an ordered
list of one or more related Application Server Processes (e.g., primary, list of one or more related Application Server Processes (e.g., primary,
secondary, tertiary, ). secondary, tertiary, ).
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup Server. Examples of Application Server Processes are primary or backup
MGC instances. MGC instances.
Application Server Process Path (ASP Path or just Path) - A Path to a 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 remote Application Server Process instance. A Path maps 1:1 to an SCTP
association. association.
Fail-over - The capability to re-route signaling traffic as required Fail-over - The capability to re-route signaling traffic as required
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Application Server Process (e.g., from primary MGC to back-up MGC). 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 Fail-over may also apply upon the return to service of a previously
unavailable Application Server Process. unavailable Application Server Process.
Signaling Link Terminal (SLT) - Refers to the means of performing all Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their of the functions defined at MTP level 2 regardless of their
implementation [2]. implementation [2].
1.3 Signaling Transport Architecture 1.3 Signaling Transport Architecture
The architecture that has been defined for SCN signaling transport The architecture that has been defined [4] for SCN signaling transport
over IP uses multiple components, including an IP transport over IP uses multiple components, including an IP transport
protocol, a signaling common transport protocol (SCTP) and an adaptation protocol, a signaling common transport protocol (SCTP) and an adaptation
module to support the functions expected by a particular SCN signaling module to support the functions expected by a particular SCN signaling
protocol from its underlying protocol layer. protocol from its underlying protocol layer.
In reference to the SIGTRAN framework architecture [4], this document In reference to the SIGTRAN framework architecture [4], this document
defines a SCN adaptation module that is suitable for the transport of defines a SCN adaptation module that is suitable for the transport of
SS7 MTP2 User. The only SS7 MTP2 User is MTP3. SS7 MTP2 User. The only SS7 MTP2 User is MTP3.
1.3.1 Case 1: SG to MGC 1.3.1 Case 1: SG to MGC
skipping to change at page 5, line 5 skipping to change at page 5, line 5
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
UDP - User Datagram Protocol UDP - User Datagram Protocol
SCTP - Simple Control Transmission Protocol SCTP - Simple Control Transmission Protocol
(Refer to Reference [5]) (Refer to Reference [5])
Figure 1: M2UA in the SG to MGC Application Figure 1: M2UA in the SG to MGC Application
Note: STPs may be present in the SS7 path between the SEP and the SG. Note: STPs may be present in the SS7 path between the SEP and the SG.
1.3.2 Case 2: SG to IPSCP 1.3.2 Case 2: SG to IPSP
The following figure shows the seamless interworking at MTP3 layer. The following figure shows the seamless interworking at the MTP3
MTP3 is adapted to SCTP layer using MTP2 User Adaptation Layer. In this layer. MTP3 is adapted to the SCTP layer using MTP2 User Adaptation
example, the Signaling Gateway can be a STP. All the primitives between Layer (M2UA). In this example, the Signaling Gateway could be an STP.
MTP3 and MTP2 are supported using MTP2 User Adaptation Layer (MTP2UA). All the primitives between MTP3 and MTP2 are supported by M2UA. Any
In the following example, the Signaling Gateway could also have SCCP of the nodes in the diagram could have SCCP or other SS7 user parts.
layer for providing Gateway Screening functionality for the IPSCP.
****** SS7 ****** IP ************ ****** SS7 ****** IP ************
*SEP *-------* SG *-------------* IPSCP * *SEP *-------* SG *-------------* IPSP *
****** ****** ************ ****** ****** ************
+----+ +---------+ +----+ +---------+
|TCAP| | TCAP | |TCAP| | TCAP |
+----+ +---------+ +----+ +---------+
|SCCP| | SCCP | |SCCP| | SCCP |
+----+ +---------+ +---------+ +----+ +---------+ +---------+
|MTP | | MTP | | MTP | |MTP | | MTP | | MTP |
|L3 | | L3 | | L3 | |L3 | | L3 | | L3 |
|L2 | +----+----+ +----+----+ |L2 | +----+----+ +----+----+
|L1 | |MTP |M2UA| |M2UA|MTP | |L1 | |MTP |M2UA| |M2UA|MTP |
| | |L2 +----+ +----+L2 | | | |L2 +----+ +----+L2 |
| | |L1 |SCTP| |SCTP|L1 | | | |L1 |SCTP| |SCTP|L1 |
| | | |----| |----| | | | | |----| |----| |
| | | |UDP | |UDP | | | | | |UDP | |UDP | |
+----+ +----+----+ +----+----+ +----+ +----+----+ +----+----+
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
IPSCP - IP Signaling Control Point IPSP - IP Signaling Point
UDP - User Datagram Protocol UDP - User Datagram Protocol
SCTP - Simple Control Transmission Protocol SCTP - Simple Control Transmission Protocol
(Refer to Reference [5]) (Refer to Reference [5])
Figure 2: M2UA in the SG to IPSCP Application Figure 2: M2UA in the SG to IPSP Application
Note that in this case, the SCTP association acts as a SS7 link between In this case, the SCTP association acts as an SS7 link between the SG
the SG and IPSCP. The IPSCP may or may not have a termination to the and the IPSP. The association contains two streams, one in each
SS7 network. direction. The IPSP may or may not have a termination to the SS7
network.
1.3.3 UDP port 1.3.3 UDP port
A request will be made to IANA to assign a UDP port for M2UA. A request will be made to IANA to assign a UDP port for M2UA.
1.4 Services Provided by the M2UA Adaptation Layer 1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
skipping to change at page 9, line 36 skipping to change at page 9, line 36
M-ASP STATUS M-ASP STATUS
2.0 Protocol Elements 2.0 Protocol Elements
This section describes the format of various messages used in this This section describes the format of various messages used in this
protocol. protocol.
2.1 Common Message Header 2.1 Common Message Header
The protocol messages for MTP2 User Adaptation require a message header The protocol messages for MTP2 User Adaptation require a message header
structure which contains a version, message type and message length. structure which contains a version, message type and message length. This
This message header is common among all SCN adaptation layers. message header is common among all SCN adaptation layers.
0 7 8 15 16 31 0 7 8 15 16 31
+---------------+---------------+ +---------------+---------------+
| Vers | Spare | Msg Type | | Vers | Spare | Msg Type |
+---------------+---------------+ +---------------+---------------+
| Message Length | | Message Length |
+-------------------------------+ +-------------------------------+
Figure 2 Common Message Header Figure 2 Common Message Header
skipping to change at page 11, line 14 skipping to change at page 11, line 14
can be left empty (a null string of length zero). The Interface Identifier can be left empty (a null string of length zero). The Interface Identifier
follows the same endpoint naming scheme provided in MGCP [7]. For example, follows the same endpoint naming scheme provided in MGCP [7]. For example,
if a Signaling Gateway terminates a E1 and the SS7 signaling link is one if a Signaling Gateway terminates a E1 and the SS7 signaling link is one
timeslot 16, the interface identifier could be the following: timeslot 16, the interface identifier could be the following:
e1/16@sgw1.example.net e1/16@sgw1.example.net
The use of wildcards is not acceptable. The use of wildcards is not acceptable.
Note: The Interface Identifier string should be padded to 32-bit Ed's Note: The Interface Identifier string should be padded to 32-bit
boundaries. The length field indicates the end of the string. boundaries. The length field indicates the end of the string.
0 15 16 31 0 15 16 31
+---------------+---------------+ +---------------+---------------+
| Tag (0x1) | Length | | Tag (0x1) | Length |
+-------------------------------+ +-------------------------------+
| Interface Identifier | | Interface Identifier |
+-------------------------------+ +-------------------------------+
skipping to change at page 18, line 42 skipping to change at page 18, line 42
that corresponds to the SS7 link. that corresponds to the SS7 link.
3.1.2 MAUP Message Procedures 3.1.2 MAUP Message Procedures
On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an
SG or MGC needs to invoke the corresponding layer primitives to the SG or MGC needs to invoke the corresponding layer primitives to the
local MTP Level 2 or MTP Level 3 layer. local MTP Level 2 or MTP Level 3 layer.
3.2 Procedures to Support Service in Section 1.4.2 3.2 Procedures to Support Service in Section 1.4.2
3.2.1 LM primitives procedures These procedures achieve the IUA layer's "Support for Communication
between Layer Managements" service.
3.2.1 Layer Management Primitives Procedure
On receiving these primitives from the local layer, the M2UA layer will On receiving these primitives from the local layer, the M2UA layer will
send the corresponding LM message (Error) to its peer. The M2UA layer send the corresponding MGMT message (Error) to its peer. The M2UA layer
must fill in the various fields of the common and specific headers must fill in the various fields of the common and specific headers
correctly. correctly.
3.2.2 LM message procedures 3.2.2 MGMT message procedures
Upon receipt of LM messages the M2UA layer must invoke the corresponding Upon receipt of MGMT messages the M2UA layer must invoke the corresponding
Layer Management primitives (M-ERROR) to the local layer management. Layer Management primitives (M-ERROR) to the local layer management.
3.3 Procedures to Support Service in Section 1.4.3 3.3 Procedures to Support Service in Section 1.4.3
These procedures achieve the M2UA layer's "Support for management of These procedures achieve the M2UA layer's "Support for management of
active associations between SG and MGC" service. active associations between SG and MGC" service.
3.3.1 State Maintenance 3.3.1 State Maintenance
3.3.1.1 ASP States 3.3.1.1 ASP States
The state of the each ASP is maintained in the M2UA layer on the SG. The The state of the each ASP is maintained in the M2UA layer on the SG. The
state of an ASP changes due to events. The events include: state of an ASP changes due to events. The events include:
* Reception messages from peer M2UA layer * Reception messages from peer M2UA layer
* Reception of indications from layers below * Reception of indications from layers below
The ASP state transition diagram is shown in Figure 4. The possible The ASP state transition diagram is shown in Figure 4. The possible states
states of an ASP are: of an ASP are:
ASP-DOWN: Application Server Process is unavailable. Initially all ASPs ASP-DOWN: Application Server Process is unavailable. Initially all ASPs
are in this state. are in this state.
ASP-UP: Application Server Process is available but application traffic is ASP-UP: Application Server Process is available but application traffic is
stopped. stopped.
ASP-ACTIVE: Application Server Process is available and application ASP-ACTIVE: Application Server Process is available and application traffic
traffic is active. At most one ASP per AS can be in the active state. is active. At most one ASP per AS can be in the active state.
Figure 4: ASP State Transition Diagram Figure 4: ASP State Transition Diagram
+-------------+ +-------------+
|-------->| | |-------->| |
| | ASP-ACTIVE | | | ASP-ACTIVE |
| | | | | |
| | | | | |
| +-------------+ | +-------------+
| ^ | | ^ |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
| Up | | SCTP CDI | Up | | SCTP CDI
| | v | | v
| +-------------+ | +-------------+
| | | | | |
|-------->| | |-------->| |
| ASP-DOWN | | ASP-DOWN |
| | | |
| | | |
+-------------+ +-------------+
SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer
Layer Protocol (M2UA) on an SG. SCTP will send this indication when Protocol (M2UA) on an SG. SCTP will send this indication when it
it detects the loss of connectivity to ASP's SCTP layer. detects the loss of connectivity to ASP's SCTP layer.
3.3.1.2 AS States 3.3.1.2 AS States
The state of the AS is maintained in the ITUN layer on the SG. The state of the AS is maintained in the ITUN layer on the SG. The
state of an AS changes due to events. These events include:
The state of an AS changes due to events. These events include:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
The possible states of an AS are: The possible states of an AS are:
AS-DOWN: Application Server is unavailable. This state implies that all AS-DOWN: Application Server is unavailable. This state implies that all
ASPs are in the ASP-DOWN state for this AS. ASPs are in the ASP-DOWN state for this AS.
AS-UP: One or more ASPs are in the ASP-UP state. AS-UP: One or more ASPs are in the ASP-UP state.
AS-ACTIVE: Application Server is available and application traffic is AS-ACTIVE: Application Server is available and application traffic is
active. This state implies that one ASP is in the ASP-ACTIVE state. active. This state implies that one ASP is in the ASP-ACTIVE state.
AS-PENDING: Currently Active ASP became inactive or SCTP association with it AS-PENDING: Currently Active ASP became inactive or SCTP association with
is lost. A Recovery timer will be started and in coming SCN messages will it is lost. A Recovery timer will be started and in coming SCN messages
be queuedby the SG. If an ASP becomes Active before the recovery timer will be queuedby the SG. If an ASP becomes Active before the recovery
expires, AS will move to AS-ACTIVE state and all the queued messages will timer (Tr) expires, the AS will move to AS-ACTIVE state and all the
be sent to the active ASP. If the recovery timer expires before an ASP queued messages will be sent to the active ASP. If the recovery timer
becomes active, SG stops queuing messages and discards all queued messages. expires before an ASP becomes active, SG stops queuing messages and
AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it discards all queued messages. AS will move to AS-UP if at least one
will move to AS-DOWN state. ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.
If T(r) expires before an ASP becomes active, the SG stops queuing messages If Tr 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 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. at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.
Ed's Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN
states, the Layer Management on MG may take appropriate SCN
notification actions.
+----------+ one ASP trans ACTIVE +-------------+ +----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| | | |------------------------>| |
| AS-UP | | AS-ACTIVE | | AS-UP | | AS-ACTIVE |
| | | | | | | |
| |< -| | | |< -| |
+----------+ \ / +-------------+ +----------+ \ / +-------------+
^ | \ Tr Trigger / ^ | ^ | \ Tr Trigger / ^ |
| | \ at least one / | | | | \ at least one / | |
| | \ ASP in UP / | | | | \ ASP in UP / | |
| | \ / | | | | \ / | |
skipping to change at page 21, line 39 skipping to change at page 21, line 39
| |<------------------------| | | |<------------------------| |
+----------+ Tr Trigger no ASP +-------------+ +----------+ Tr Trigger no ASP +-------------+
in UP state or in UP state or
prev ACTIVE ASP trans prev ACTIVE ASP trans
to DOWN state to DOWN state
Tr = Recovery Timer Tr = Recovery Timer
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the
Layer Management on MG may take appropriate SCN notification actions.
3.3.2 ASPM procedures for primitives 3.3.2 ASPM procedures for primitives
Before the establishment of an SCTP association the ASP state at both the Before the establishment of an SCTP association the ASP state at both the
SG and ASP is assumed to be "Down". SG and ASP is assumed to be "Down".
When the M2UA layer receives an M-SCTP ESTABLISH request primitive from When the M2UA layer receives an M-SCTP ESTABLISH request primitive from
the Layer Management, the M2UA layer will try to establish an SCTP the Layer Management, the M2UA layer will try to establish an SCTP
association with the remote M2UA peer. Upon reception of an eventual association with the remote M2UA peer. Upon reception of an eventual
SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management.
skipping to change at page 26, line 5 skipping to change at page 31, line ?
Retrieval Confirm ----------> Retrieval Confirm ---------->
Retrieval Ind -----------> Retrieval Ind ----------->
Retrieval Ind -----------> Retrieval Ind ----------->
Rtrvl Complete Ind ----------> Rtrvl Complete Ind ---------->
Note: The number of Retrieval Indication is dependent on the number of Note: The number of Retrieval Indication is dependent on the number of
messages in the retransmit queue that have been requested. Only one messages in the retransmit queue that have been requested. Only one
Retrieval Complete Indication should be sent. Retrieval Complete Indication should be sent.
4.3 Case 2: SG to IPSCP, MTP Level 2 to MTP Level 3 Boundary Procedures 4.3 Case 2: SG to IPSP, MTP Level 2 to MTP Level 3 Boundary Procedures
4.3.1 Message Transmission In general, messages passed between MTP3 and M2UA are the same as
those passed between MTP3 and MTP2. M2UA interprets messages from MTP3
and sends the appropriate message to SCTP. Likewise, messages from
SCTP are used to generate a meaningful message to MTP3.
Messages are transmitted using the Data Request primitive from MTP3 to 4.3.1 Link Initialization (Alignment)
MTP2UA.
MTP2UA MTP3 The MTP3 layer can request that an SS7 link be brought into alignment
using the normal or emergency procedure. An example of the message
flow to bring an SS7 link in-service is shown below.
<------------- Message For Transmission (Data Request) There are two alignment procedures normal alignment and emergency
alignment. During normal alignment, communication to the other end is
tested for a period of time to make sure that the communication link
satisfies the performance requirements of the application. The
examples are RTT and packet loss. Normal alignment is used when there
are other links available to the same destination. Emergency alignment
is used when there are no other links to the same destination. During
emergency, the link is not tested for a long period of time. Instead,
an indication from the SCTP layer is used to bring the link in
service.
4.3.2 Message Reception The procedure for beginning an Association is described in the SCTP
standard [5].
Messages are received using the Data Indication primitive from MTP2UA to MTP3 M2UA SCTP SCTP M2UA MTP3
MTP3. ---- ---- ---- ---- ---- ----
MTP2UA MTP3 Power On
------------>
------------> Received Message (Data Indication) Out of Service
<------------
4.3.3 Link Status Indication Emergency OR
Emergency Ceases
------------>
The MTP2UA layer sends Link_In_Service and Link_out_Of_Service after Start
receiving indication from SCTP layer. ------------>
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 Associate
------------>
<-------------- (SCTP Association
Communication Up procedure)
Link proving is done
By MTP2UA at this moment.
<---------------
Link_In_Service
<-------------- Communication Up Communication Up
Communication Lost <------------ ------------>
<---------------
Link Out of Service
4.3.4 Link Alignment Indication Indication
(Link In Service) (Link In Service)
<------------ ------------>
The MTP3 layer in the IPSCP can request that a SS7 link be brought into For the Emergency Ceases case, proving begins at this time. See the
alignment using the normal or emergency procedure. An example of the section on Link Proving below.
message flow to bring a SS7 link in-service using the normal alignment
procedure is shown below.
MTP2UA MTP3 4.3.2 Link Proving
<----------- Establish Request (ESTABLISH_NORMAL) One function of the adaptation layer is to make sure that the link
Establish Response ----------> meets the performance requirements of the application. This is
usually done by proving the link. For example, for proving the link,
we need the adaptation layer to issue an heartbeat/RTT to its peer.
This is done before declaring link is in service to its application.
For this purpose, the existing "status" command is used. Note how the
link meets performance requirements is implementation dependent.
Also, the proving period can be configurable.
An example of the message flow to bring a SS7 link in-service using the Proving is done by both ends of the link. To simplify the diagram,
emergency alignment procedure. proving is shown on one end only.
MTP2UA MTP3 In the following diagram the Link has just completed the alignment
procedure.
<----------- Establish Request (ESTABLISH_EMER) The Status primitive is sent to determine if the Heartbeats were
Establish Response ----------> delivered successfully within the desired time period.
4.3.5 Link Proving (During Emergency) MTP3 M2UA SCTP SCTP M2UA MTP3
---- ---- ---- ---- ---- ----
There are two alignment procedures used: normal alignment and emergency Request Heartbeat
alignment. During normal alignment, communication to other end is tested ------------>
for a period of time for making sure that the communication link does (Heartbeat sent
satisfy the performance requirements of the application. The examples and acknowledged)
are RTT and packet loss. Normal alignment is used when there are other Request Heartbeat
links associated with the affected link. The other links should be to ------------>
the same destination. Emergency alignment is used when there are no other (Heartbeat sent
links to the same destination. During emergency, link is not tested for and acknowledged)
long period of time but instead, an indication from SCTP layer is used to
bring the link in service.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 Request Heartbeat
------------>
(Heartbeat sent
and acknowledged)
-------------> Heartbeats are sent for M seconds (Note A).
Emergency Disable Proving
<------------- Status
Communication UP ------------>
-------------->
Status (validate the SCTP association meets
application requirement)
<------------- Indication
Link_In_Service (Link In Service) (After checking that link is sane)
<------------
4.3.6 Link Proving (Emergency Ceased) Note A M is implementation-dependent.
One function of the adaptation layer is to make sure that the link meets 4.3.3 Message Transmission and Reception
the performance requirements of the application. This is usually done
by proving the link. For example, for proving the link, we need the
adaptation layer to issue an heartbeat/RTT to its peer. This is done
before declaring link is in service to its application. For this purpose,
the existing "status" command is used. Note that how to the link meets
performance requirements is implementation dependent. Also, the proving
period can be configurable.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 Messages are transmitted using the Data Request primitive from MTP3 to
M2UA. The diagram shows the case where the Link is In Service. The
message is passed from MTP3 of the source to MTP3 of the destination.
-------------> MTP3 M2UA SCTP SCTP M2UA MTP3
Emergency Enable Proving ---- ---- ---- ---- ---- ----
ceased
<--------------- Request
Communication UP (Message for
---------------> RTT transmission)
Status --------> ------------>
RTTs are -------->
Sent for a -------->
Period of .........
3 seconds -------->
RTT
<--------------
Link_In_Service (After checking that link is sane)
4.3.7 Congestion Notification to Upper layer Send
------------>
MTP3 layer expects notification of the link congestion. For example, this (SCTP sends message)
is accomplished by two messages: I) Link Congested ii) Link Congestion
Ceased. Congestion is assumed if MTP2UA layer notices repeated failures
to send requests to SCTP (this is implementation dependent and it is
assumed that the SEND Failure has an error code "life time expired").
Subsequently MTP2UA can start polling status of SCTP. If all the messages
are successfully transmitted over a period of time (implementation dependent)
then it is assumed that the congestion is abated. If the congestion
condition should continue, the link will be taken out of service. In
this case, it is possible to start link change over procedure.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 Receive
------------>
Indication
(Received message)
------------>
4.3.4 Link Status Indication
The M2UA layer sends an indication that the Link is In Service or Out
of Service after receiving a Communication indication from the SCTP
layer. In either case, MTP3 responds in its usual way.
MTP3 M2UA SCTP SCTP M2UA MTP3
---- ---- ---- ---- ---- ----
Communication Up
<------------
(If Emergency Ceases,
Link proving is done
by M2UA now.)
Indication
(Link In Service)
<------------
MTP3 M2UA SCTP SCTP M2UA MTP3
---- ---- ---- ---- ---- ----
Communication Lost
<------------
Indication
(Link Out of Service)
<------------
4.3.5 Congestion Notification to Upper layer
MTP3 layer expects notification of the link congestion. For example,
this is accomplished by two messages 1) Link Congestion Onset 2) Link
Congestion Abated. Congestion is assumed if M2UA layer notices
repeated failures to send requests to SCTP (this is implementation
dependent and it is assumed that the SEND Failure has an error code
"life time expired"). Subsequently M2UA can start polling status of
SCTP. If all the messages are successfully transmitted over a period
of time (implementation dependent) then it is assumed that the
congestion is abated. If the congestion condition should continue,
the link will be taken out of service. In this case, it is possible
to start the link changeover procedure.
The US National version of SS7 has congestion levels. For US National
SS7, the Indication primitive for Congestion Onset should report the
congestion level.
In the example below, M2UA has sent a message to SCTP.
MTP3 M2UA SCTP SCTP M2UA MTP3
---- ---- ---- ---- ---- ----
<--------------
Send Failure Send Failure
<-------------- <------------
Send Failure Send Failure
<-------------- <------------
Send Failure Send Failure
("N" consecutive fails) <------------
(implementation specific) "N" consecutive fails -
<------------- implementation specific
Congestion Detected
-------------> Indication
(Congestion Onset)
<------------
Status Status
------------> ------------>
Status Status
-------------> ------------>
polled for certain time
till the congestion ceased
(implementation specific)
<--------------
Congestion ceased
4.3.8 Link Change Over due to Congestion Status
------------>
polled for certain time until
congestion ceases -
implementation specific
Due to sustained congestion, MTP2UA can take the link out of service. Indication
Next, MTP2UA sends an indication to MTP3 regarding link is out service (Congestion Abatement)
due to congestion. In this context, MTP3 can initiate a link change <------------
over to its peer.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 4.3.6 Link Deactivation
<-------------- The MTP3 can request that a SS7-IP link be taken out-of-service. It
Send Failure uses the Release Request message as shown below.
<--------------
Send Failure MTP3 M2UA SCTP SCTP M2UA MTP3
<-------------- ---- ---- ---- ---- ---- ----
Send Failure
("N" consecutive fails) Request
(implementation specific) (Deactivate Link)
<--------------
Congestion Detected
------------> ------------>
Terminate Terminate
<------------ ------------>
Terminate Successful Terminate Successful
<------------ <------------
Communication Lost Communication Lost
<--------------- <------------
Link Out of Service
4.3.9 Link Release Indication
(Link Out of Service)
<------------
The MTP3 can request that a SS7-IP link be taken out-of-service. It uses 4.3.7 Link Changeover
the Release Request message as shown below.
MTP2UA MTP3 The objective of the changeover is to ensure that signaling traffic
carried by the unavailable signaling link is diverted to the
alternative signaling link as quickly as possible while avoiding
message loss, duplication, or mis-sequencing. For this purpose, the
changeover procedure includes data retrieval, which is performed
before reopening the alternative signaling links to the diverted
traffic. Data retrieval consists of identifying all those messages in
the retransmission buffer of the unavailable signaling link which have
not been received by the far end. Retrieval includes transferring the
concerned messages to the transmission buffers of the alternative
links. In order to support changeover, the SCTP SSN must be used in
place of the FSN/BSN of SS7.
<------------ Release Request Stream Sequence Numbers used by SCTP (Signaling Control Transport
Release Response ------------> Protocol) are sixteen bits long. MTP2's forward and backward sequence
numbers are only seven bits long. Hence it is necessary to modify
MTP3 to accomodate the larger SSNs. Reference [7] can be used as a guide
for the MTP3 changes.
The SG can autonomously indicate that a SS7 link has gone out-of-service For data retrieval, MTP3 requests Backward Sequence Number (BSN) from
as shown below. M2UA. This is the sequence number of the last message received by the
local end. During normal period, SCTP delivers ordered messages to
the application. However, during congestion or failure condition, the
sequence numbers of the acknowledged messages can have gaps. In
particular, the SACK (selective acknowledgement message) message can
have several of these gaps. Hence, it is important to scan through
these gaps and find the sequence number before first gap. This is the
number from which the remote end has to transmit the messages. So,
this is the number considered as the Backward Sequence Number and
communicated to the remote end. In a similar way, the remote end also
detects the BSN and indicates to local end. As soon as the MTP3 of the
local end receives this BSN, MTP3 retrieves all the unacknowledged
messages starting from BSN. This is accomplished through "Retrieve
FSN" message. After all the messages are sent from M2UA to MTP3, a
retrieval complete message is sent.
MTP2UA MTP3 Note that the sequence numbers and messages requested by MTP3 are sent
from SCTP to M2UA in the Communication Lost primitive.
Release Indication ------------> MTP3 M2UA SCTP SCTP M2UA MTP3
(Link_Out_Of_Service) ---- ---- ---- ---- ---- ----
NOTE: We may be able to effective use of "State" primitives here. Communication Lost
For further investigation <------------
4.3.10 Link Change Over Indication
(Link Out of Service)
<------------
The objective of the change over is to ensure that signaling traffic Request
carried by the unavailable signaling link is diverted to the alternative (Retrieve BSN)
signaling link as quickly as possible while avoiding message loss, ------------>
duplication or mis-sequencing. For this purpose, the changeover
procedure includes data retrieval, which is performed before reopening
the alternative signaling links to the diverted traffic. Data retrieval
consists of identifying all those messages in the retransmission buffer
of the unavailable signaling link which have not been received by the far
end. Retrieval includes transferring the concerned messages to the
transmission buffers of the alternative links. In order to support
changeover, the SCTP TSN must be mapped to FSN/BSN of SS7.
Transmit Sequence Numbers used by SCTP (Signaling Control Transport (M2UA locates
Protocol) are of sixteen bits. MTP2's forward and backward sequence first gap in
numbers of only seven bits. Hence it is required to map the sixteen bit received messages)
TSN to seven bit FSN/BSN. For simplicity, it is assumed that only least
seven significant seven bits of TSN are used. There can be a
configuration, where the links in the link set are of not equal bandwidth.
Further investigation is required for this scenario.
15 8 0 Indication
---------------------------------------------- (Indicate BSN)
0 0 0 0 0 0 0 0 0 X X X X X X X <------------
-----------------------------------------------
<------FSN/BSN-----> Request - COO (BSN) on another link
------------------------------------------------------------>
In order to convert TSN to FSN and BSN, the following formula is used: Request
(Retrieve BSN)
<------------
FSN, BSN = (Transmit Sequence Number - 1) MODULO 255 Indication
(Indicate BSN)
------------>
For data retrieval, MTP3 requests Backward Sequence Number (BSN) from Request - COA (BSN)
MTP2UA. This the sequence number of the last message received by the <------------------------------------------------------------
local end. During normal period, SCTP delivers ordered messages to the
application. However, during congestion or failure condition, the sequence
numbers of the acknowledged messages can have gaps. In particular, the
SACK (selective acknowledgement message) message can have several of these
gaps. Hence, it is important to scan through these gaps and find the
sequence number before first gap. This is the number from which the remote
end has to transmit the messages. So, this is the number considered as Request
the Backward Sequence Number and communicated to the remote end. In a (Retrieve FSN)
similar way, the remote end also, detects the BSN and indicates to local ------------>
end. As soon, the MTP3 of local end receives this BSN, MTP3 retrieves all
the unacknowledged messages starting from BSN. This is accomplished
through "Retrieve FSN" message. After all the messages are sent from
MTP2UA to MTP3, a retrieval complete message is sent.
MTP3 MTP2UA SCTP SCTP MTP2UA MTP3 (M2UA locates
first gap in
acknowledgements)
<------------- Indication
Communication Lost (FSB Not retrievable) (in case)
<-------------- <------------
Link Out of Service
--------------> Find the gaps Indication
Retrieve BSN in the rcvd. Msgs (Retrieved Message)
And locate the first gap <------------
<---------------
Indicate BSN
---------------------------------------------------------------->
COO (BSN)
<-----------
Retrieve BSN
----------->
Indicate BSN
<-----------------------------------------------------------------
COA (BSN)
--------------------->Go through the transmit Indication
Retrieve FSN queue and find unack. Msgs. (Retrieved Message)
<--------------------- FSB Not retrievable (in case) <------------
<--------------------- Retrieved Message
<----------------------Retrieved Message Indication
... (Retrieval Complete)
<----------------------Retrieval Complete <------------
Send messages on another link.
4.4 Layer Management Communication Examples 4.4 Layer Management Communication Examples
An example of the message flows for communication between Layer Manage- An example of the message flows for communication between Layer Manage-
ment modules between SG and MGC is shown below. An active association ment modules between SG and MGC is shown below. An active association
between MGC and SG is established (section 4.1) prior to the following between MGC and SG is established (section 4.1) prior to the following
message flows. message flows.
SG MGC SG MGC
skipping to change at line 1586 skipping to change at page 32, line 34
[4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran-
framework-arch-03.txt, June 1999 framework-arch-03.txt, June 1999
[5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt,
August 1999 August 1999
[6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp-
v1-03.txt, August 1999 v1-03.txt, August 1999
[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T
Recommendation Q.2140'
8.0 Author's Addresses 8.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Malleswar Kalla Tel: +1-973-829-5212 Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: kalla@research.telcordia.com Telcordia Technologies EMail: kalla@research.telcordia.com
skipping to change at line 1610 skipping to change at line 1685
Greg Sidebottom Tel: +1-613-763-7305 Greg Sidebottom Tel: +1-613-763-7305
Nortel Networks EMail: gregside@nortelnetworks.com Nortel Networks EMail: gregside@nortelnetworks.com
3685 Richmond Rd, 3685 Richmond Rd,
Nepean, Ontario Nepean, Ontario
Canada K2H5B7 Canada K2H5B7
Ram Dantu, Ph.D. Tel: +1-972-477-8446 Ram Dantu, Ph.D. Tel: +1-972-477-8446
Alcatel USA EMail: ram.dantu@usa.alcatel.com Alcatel USA EMail: ram.dantu@usa.alcatel.com
1000 Coit Road 1000 Coit Road
Plano, Tx. 74075 Plano, TX 74075
This Internet Draft expires April 2000. Tom George Tel: +1-972-519-3168
Alcatel USA EMail: tom.george@usa.alcatel.com
1000 Coit Road
Plano, TX 74075
This Internet Draft expires June 2000.
 End of changes. 

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