| draft-bressler-sigtran-ipss7l2-00Description: Request For CommentsYou can download source copies of the file as follows:
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 [email protected] 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: Wed, 27 Nov 2024 04:51:06 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |