Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-bressler-sigtran-ipss7l2-00

Description: Request For Comments

You can download source copies of the file as follows:

draft-bressler-sigtran-ipss7l2-00.txt in text format.

Listed below is the contents of file draft-bressler-sigtran-ipss7l2-00.txt.


Internet Engineering Task Force                        William Bressler
Internet Draft                                          NORTEL Networks
  
Expires in Six Months               	                    January 1999

                         SS7 Level Two over IP
                  <draft-bressler-sigtran-ipss7l2-00.txt>

Status of this Memo

This document is an Internet Draft.  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.  
Internet Drafts may be updated, replaced, or obsoleted by other 
documents at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working  draft" or
"work in progress".

To learn the current status of any Internet-Draft, please check the 
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.

1 Abstract
   
This document proposes the use of TCP/IP as the transport protocol for 
common channel signaling, Signaling System #7 (SS7).
 
The migration from the current 56k/64k physical layer to an IP based 
transport will reduce the cost associated with dedicated trunk based 
link. Also, the current signaling point (SP) network using quasi-
associated architecture will be maintained to make the transition as 
seamless as possible. 

2  Scope

This draft defines the encapsulation of SS7 signal units (SU) in a TCP
packet. The concept of a physical link will be maintained, which will 
emulate the current SS7 links and link control mechanisms.

2.1  Quasi-associated Network Architecture

The scope of network architecture in this recommendation is limited to 
the use of quasi-associated SP's. It is assumed that the current SS7 
network will be intact with IPlink phased in as the technology proves 
itself as a cost effective, reliable alternative. Using the current 
quasi-associated SS7 networks also decreases the number of hops between
SP's and the number of endpoints to a minimum. Each SP would have two 
IP addresss (two IPlinks) in addition to its current point code(s).

Bressler                                                              1
2.2  IP Signaling Link (IPlink)

The scope of IP signaling link, IPlink, in this Recommendation includes 
the following:

- A link will be identified by an IP address
- The link alignment procedure.
- The emergency link alignment procedure.
- The link Basic Error Rate (BER) monitor.
- The link Alignment Error Rate (AER) monitor. 
- Either software or hardware shall calculate SU CRC-16 checksums. 
- Preventative Cyclic Retransmission (PCR) shall be the default 
  forward error correction.
- Signaling message handling.
- MSU load sharing.

3  Quasi-associated Network

A quasi-associated network between a signaling service point (SSP) and 
a signaling transfer point (STP) is shown below. Currently, SS7 
messaging traverse from SSP through the STP to another SSP using T1 
trunking, which is very reliable, and is configured for redundancy 
(not shown). If the IP network is to be a viable alternative to T1 
trunking, it must be able to demonstrate at least equal reliability and
alternate routing capabilty. 

                          SS7 Messaging

                            T1 trunk
       ------------------------------------------------------
      |                          |                          |
      V                          V                          V
   -------   --------------   -------   --------------   -------
   | SSP |<->| IP Network |<->| STP |<->| IP Network |<->| SSP | 
   -------   --------------   -------   --------------   -------

3.1 Network Nodes

Current network topology should be unchanged. SSP, STP, signaling 
control point (SCP), authentication centers (AC), customer service 
centers (CSC), home location register (HLR), visiting location register
(VLR), etc., will all be accessible.

3.2 Signaling Link

Each link will have it's own IP address and processor. This will
maintain the current link concepts intact for reliability, 
redundency, alignment, changeover/changeback, load sharing, etc.

IPlinks should have the same behaviour as the current SS7 links to
gain acceptance into the existing network architecture. SS7 <-> IP-SS7
interworking should be as transparent as possible.

Bressler                                                              2
4  TCP encapsulation

The current SS7 protocol is to be used as is. It provides a high 
reliability transport for telephony information. TCP packets will be 
used to carry the current SS7 messaging. This greatly reduces the risk
of IP-SS7 by eliminating the need for new protocols. Telephony vendors 
already offer IP connectivity on their STP products. The largest MSU 
allowed, 272 octets, easily fits in a TCP packet.

-------------------------------
|   TCP Header   |   SS7 SU   |
-------------------------------

5  SS7 CRC-16 Checksum

The reliability of the SS7 network is due in large part to the use of a
CRC-16 checksum, calculated by hardware. This same reliability must be 
used in IPlink. Currently, existing hardware will most likely not 
support the encapsulation of the SS7 packet after the checksum has been 
calculated. The CRC-16, while cumbersome, will have to be performed in
software. This can be speeded up greatly by the use of table driven 
calculations.

6  L2 Timers

Since the CRC-16 is computed in software, the L2 timers for IPlink have
been extended. 

T1 (aligned/ready)      20 Sec
T2 (not aligned)        30 Sec
T3 (aligned)            20 Sec
T4 (Pn)                  5 Sec
T4 (Pe)                  2 Sec
T5 (SIB)               500 ms
T6 (remote congestion)   6 Sec
T7 (ACK delay)           2 Sec

7  FISU Transmitting

Currently, SS7 links will send fill-in SUs (FISU) continuously, 
separated only by an HDLC flag (value 7E hex). To reduce processing 
overhead in IPlink, FISU's will be transmitted under the following 
conditions:

- A FISU will be transmitted every 20 ms (Tfs) while the links are 
  aligned.
- A FISU may be sent at any time to ACK/NACK MSU's.

The FISU transmit timer is reset to Tfs after the transmission of any 
SU (FISU, LSSU, MSU).

Bressler                                                              3
8 IPlink Error Detection

Since L2 no longer has any knowledge of the physical media over which 
it is carried, detectable errors such as framing bit errors, abort 
sequences etc., no longer apply. Error detection will be based on 
either the expiry of a timer or the detection of CRC-16 checksum 
errors. 

8.1 IPlink Receive Timeout

A timer to detect IPlink receive failure will be set to 200ms (Tipr). 
This timer will be reset after the receipt of any type SU. IPlink timer 
expiry will force the IPlink to the out of service state. 

8.2  IPlink Transmit Timeout

A timer to detect IPlink transmit failure will be set to 1 Sec (Tipt).
This timer will be reset after the the successful transmission of any 
type SU. IPlink timer expiry will force the IPlink to the out of 
service state.

8.3  IPlink Excessive Delay

Ping (or other similar tool) will be used to measure IPlink delay. The
rate at which the delay is to be measured will be set to 5 Secs (Tipd).
This timer will be reset after the receipt of the ping response. The 
IP address of the ping will be the other end of the IPlink. Excessive
link delay will trigger either congestion or PCR.
 

9  IPlink Loading

Current link engineering guidelines are set to have a maximum load of 
0.4 erlang per link. This allows a link to take the load of a failed 
link (0.8 erlang total) and still have abundant overhead for 
processing. The processor(s) used for IPlink applications should follow
similar guidelines. 

9.1  IPlink CPU Utilization

CPU percent utilization could be monitored for 60% idle time as the 
minimum recommended for reliable operation if the changeover procedure 
is invoked. 

10 IPlink PCR

At this time, network delays are expected to be between the current T1
and satellite delays. These delays are also expected to vary widely 
from minimum to maximum (allowed) with time. PCR dictates re-
transmitting MSU's when:

Bressler                                                              4
- There is no new MSU to be transmitted.
- There is no LSSU to be transmitted.

Since IPlink delays are being monitored, PCR is enabled/disabled by the
threshold times Tpcrst (PCR start) and Tpcrsp (PCR stop), with initial 
values of 400ms and 200ms respectively.

11  IPlink Signal Unit Error Rate Monitor

This procedure is unchanged from the current procedure.

12  IPlink Alignment Error Rate Monitor

This procedure is unchanged from the current procedure.

13  IPlink L2 Flow Control

This procedure is unchanged from the current procedure.
 

14  IPlink Processor Outage

This procedure is unchanged from the current procedure.

15  IPlink ACK/NACK

This procedure is unchanged from the current procedure

16  IPlink Busy

This procedure is unchanged from the current procedure 

17  IPlink BER

This procedure will not be used as the physical media is unknown.

18  IPlink Retransmission

This procedure is unchanged from the current procedure 

19  IPlink Message Sequencing

This procedure is unchanged from the current procedure

20  IPlink Identification

The the IPlink is identified by an IP address. Most SSPs are small and 
require only two IPlinks, other SPs will require more.

Bressler                                                              5
Authors' Addresses
  
  William Bressler
  Nortel Networks
  2201 Lakeside Blvd.
  Richardson, TX 75082
  bressler@nortelnetworks.com
  
Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any  
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION  
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires in Six Months               	                    January 1999
Bressler                                                              6


Last modified: Thu, 13 Nov 2014 09:38:18 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.