Internet Engineering Task Force INTERNET-DRAFT Author Transport Working Group Greg Sidebottom Category: Informational Nortel Networks February 1999 Expires: September 1999 Functional Description of SSCOP < draft-side-sigtran-ips7-rtsp-00.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document provides a functional description of the services provided by the Service Specific Connection Oriented Protocol (SSCOP) as described in ITU Recommendation Q.2110. SSCOP performs connection control, transfer of variable length user data units, sequence integrity, error correction, and flow control functions to its users. These services are currently used to support the transport requirements of signalling applications which require reliable, ordered, low-latency transfer over large bandwidth paths. Although SSCOP is currently defined to transfer information between Layer 3 entities across the UNI and NNI using ATM virtual channels it may be possible to apply the same concepts to provide transfer of information over UDP/IP. sidebottom Informational [Page 1] INTERNET-DRAFT Functional Description of SSCOP Table of Contents 1. Introduction..............................................3 1.1 Overview................................................3 1.2 Scope...................................................3 2. Signaling Transport Requirements..........................3 2.1 Functional Requirements.................................3 2.2 Performance Requirements................................5 3. Services Provided by SSCOP................................5 3.1. Connection Establishment................................5 3.2. Connection Release......................................5 3.3. Assured Data Transfer...................................5 3.4. Unassured Data Transfer.................................6 3.5. Resynchronization.......................................6 3.6. Recovery................................................6 4. Functions of SSCOP........................................6 4.1 Transfer of User Data...................................6 4.2 Ordered Delivery........................................7 4.3 Error Correction (Retransmission).......................7 4.4 Flow Control............................................7 4.5 Keep-Alive..............................................7 4.6 Local Data Retrieval....................................8 4.7 Connection Control......................................8 5. Acknowledgements..........................................8 6. References................................................8 Author's Address.............................................8 sidebottom Informational [Page 2] INTERNET-DRAFT Functional Description of SSCOP 1. Introduction 1.1 Overview This document provides a functional description of the services provided by the Service Specific Connection Oriented Protocol (SSCOP) as described in ITU Recommendation Q.2110 [3]. SSCOP performs connection control, transfer of variable length user data units, sequence integrity, error correction, and flow control functions to its users. SSCOP, together with an appropriate Service Specific Coordination Function (SSCF) [4] [5] layer supports the communication between Layer 3 Signalling entities such as DSS2 [6] and SS7 MTP [7] which requires reliable, ordered, low-latency transfer over large bandwidth paths. Although SSCOP is currently defined to transfer information between Layer 3 entities using ATM virtual channels it may be possible to apply the same concepts to provide for the transport of information over UDP/IP. 1.2 Scope As described in the Architectural Framework for Signaling Transport [1], signaling transport focuses on transparent transport of message-based signaling protocols over IP networks. The scope of this work includes definition of encapsulation methods, end-to-end protocol mechanisms and use of IP capabilities such as differentiated services to support the functional and performance requirements for signaling. SSCOP provides a basic mechanism for reliable transport of the signaling payloads. SSCOP does not address other needs such as encapsulation/identification of the signalling protocol, security extensions, multiplexing, etc. 2. Signalling Transport Requirements 2.1. Functional Requirements SSCOP addresses the following functional requirements detailed in [1] 1) Transport of a variety of SCN protocol types, such as the application and user parts of SS7 (including ISUP, SCCP, TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG). SSCOP potentially could provide the basic transport of a variety of SCN protocol types given that, together with appropriate SSCF layers, SSCOP already supports the transfer of MTP3 and DSS-2 messages between signalling entities. SSCOP is in operation today in the support of SS7 High-speed links for SS7 networks. sidebottom Informational [Page 3] INTERNET-DRAFT Functional Description of SSCOP 2) Provide an identifier for the particular SCN protocol being transported. Not addressed. A layer above SSCOP would be required. 3) Provide a common base protocol defining header formats, security extensions and generic requirements for signaling transport, and support extensions as necessary to add individual SCN protocols if and when required. SSCOP addresses only the generic signalling transport requirements. 4) In conjunction with the underlying network protocol (IP) and transport protocol (TCP, UDP or other), provide the relevant functionality as defined by the appropriate SCN lower layer. SSCF/SSCOP can today provide the complete SCN lower layer functionality required by SS7 MTP3 and Q.2931. SSCOP can support flow control, in-sequence delivery of signalling messages, retransmission, and information on the availability of peer entities. SSCOP does not address logical identification of signalling entities/physical interfaces or loadsharing over multiple signalling transport sessions. These requirements would need to be provided in a layer above SSCOP. However, SSCOP is not today designed to operate over UDP|TCP/IP. SSCOP operates over an ordered unreliable lower layer service. 5) Support the ability to multiplex several higher layer SCN sessions on one underlying signaling transport session. This allows, for example, the output of several DSS1 D-Channel sessions to be carried in one signaling transport session. Not addressed. A layer above SSCOP would be required. 6) Be able to transport complete messages of greater length than the underlying SCN segmentation/reassembly limitations. For example, signaling transport should not be constrained by the length limitations defined for SS7 lower layer protocol (e.g. 272 bytes in the case of narrowband SS7) but should be capable of carrying longer messages without requiring segmentation. Supported. 7) Allow for a range of suitably robust security schemes to protect signaling information being carried across networks. For example, signaling transport shall be able to operate over proxyable sessions, and be able to be transported through firewalls. Not addressed. sidebottom Informational [Page 4] INTERNET-DRAFT Functional Description of SSCOP 8) Provide for congestion avoidance on the Internet, by supporting appropriate controls on signaling traffic generation (including signaling generated in SCN) and reaction to network congestion. SSCOP does contain functions that could assist in congestion avoidance but study would likely be required to make the congestion mechanisms more IP network-friendly. 2.2 Performance requirements The performance requirements are contained in draft-seth-sigtran-req-00.txt [8] 3. Services provided by SSCOP 3.1 Connection Establishment SSCOP connection establishment is initiated by an SSCOP User request. A BEGIN message is sent by the initiating SSCOP to an SSCOP peer. The BEGIN requests the clearing of the peer's transmitter and receiver buffer and initialization of the peer's transmit and receive state variables. The SSCOP peer informs the peer SSCOP User of the connection request and based on the user response, responds with either a BEGIN ACKNOWLEDGE or BEGIN REJECT Message to accept or reject the connection request. 3.2 Connection Release SSCOP connection release is initiated by a user request. An END message is sent by the SSCOP initiating the release and an END ACKNOWLEDGEMENT message is sent in response by the SSCOP peer. The peer SSCOP user is informed of release. 3.3 Assured Data Transfer The SEQUENCED DATA message is used by the SSCOP peers to transfer across an SSCOP connection sequentially numbered PDUs containing information fields provided by the SSCOP User. A POLL message is used to request status information about the peer SSCOP entity. The POLL Message contains a Poll sequence number, and the sequence number of the next expected SEQUENCED DATA message. A SOLICITED STATUS message is used by the peer to respond to the POLL message. The SOLICITED STATUS message contains information regarding the reception status of SEQUENCED DATA messages (next expected SEQUENCED DATA message & a list of missing SEQUENCED DATA messages, sidebottom Informational [Page 5] INTERNET-DRAFT Functional Description of SSCOP identified by their sequence numbers), window credit information for the peer transmitter and the sequence number of the related POLL message to which it is responded. An UNSOLICITED STATUS message is used to immediately respond to the detection of one or more missing SEQUENCED DATA messages based on the examination of the sequence numbers of received messages. The UNSOLICITED STATUS also contains window credit information for the peer transmitter and the sequence number of the next expected SEQUENCED DATA message. 3.4 Unassured Data Transfer The UNNUMBERED DATA message is used to send unacknowledged unsequenced information between SSCOP peers. These messages may be lost without notification or retransmission. UNNUMBERED DATA message transfer is requested by the SSCOP User. 3.5 Resynchronization RESYNCHRONIZATION and RESYNCHRONIZATION ACKNOWLEDGEMENT messages are used by SSCOP peers to resynchronize the buffers and data transfer state variables. 3.6 Recovery ERROR RECOVERY an ERROR RECOVERY ACKNOWLEGEMENT messages exchanged to recover from protocol error situations without releasing the connection. 4. Functions of SSCOP 4.1 Transfer of User Data This function supports the Assured or Unassured delivery service requests from the SSCOP user. For Unassured delivery, UNNUMBERED ACKNOWLEDGEMENT messages are used. Delivery of these messages is not ACKed or NACKed by the receiver and do not contain a sequence number. For Assured delivery service, SEQUENCED DATA messages are used. Delivery of these messages is ACKed/NAKed within the POLL/SOLICITED_STATUS exchange or by UNSOLICITED STATUS messages. Note: the ACK/NACK mechanism is thus "out-of-band" and does not add overhead to the SEQUENCED DATA message exchange. NAKed messages (identified by their sequence numbers) are retransmitted by a selective reject mechanism. Retransmission requests are treated with priority (i.e., sent ahead of other messages waiting to be sent. Note that at the receiver, detection of a missing sequence number (or group) results in an immediate UNSOLICITED STATUS message to the sidebottom Informational [Page 6] INTERNET-DRAFT Functional Description of SSCOP transmitter requesting retransmission. UNSOLICITED STATUS messages are only sent once with respect to a particular missing sequence number. Thereafter, the missing sequence number will appear on a list of missing numbers in the SOLICITED STATUS message. 4.2 Ordered Delivery (Sequencing) This function preserves the order of PDUs provided by the SSCOP User for transfer to a peer SSCOP User. This is accomplished by the use of sequentially numbered SEQUENCED DATA messages between the SSCOP peers. SEQUENCED DATA messages received out of order are buffered until the missing message(s) are received, unless the message contains a sequence number that could not be expected given the next sequence number expected and the size of the window granted to the transmitter (these are discarded). This mechanism will result in the deletion of duplicated messages. 4.3 Error Correction (Retransmission) When a message is received with an unexpected sequence number or a POLL/SOLICITED STATUS exchange determines that there is a gap in the send sequence, an UNSOLICITED STATUS message is sent immediately, requesting retransmission of the missing message(s). NAKed messages (identified by their sequence numbers) are retransmitted by a selective reject mechanism. Retransmission requests are treated with priority (i.e., sent ahead of other messages waiting to be sent. Note that at the receiver, detection of a missing SEQUENCED DATA message (or group) results in an immediate UNSOLICITED STATUS message to the transmitter requesting retransmission. UNSOLICITED STATUS messages are only sent once with respect to a particular missing SEQUENCE DATA message. Thereafter, the missing SEQUENCE DATA message will appear on a list of missing messages in the SOLICITED STATUS message. 4.4 Flow Control Flow Control is maintained through the use of a sliding window mechanism. The POLL/SOLICITED STATUS exchange and UNSOLICITED STATUS messages accomplish the acknowledgement of the delivery of SEQUENCED DATA messages. ACKs indicate successful delivery to the remote SSCOP peer and thus these messages can be deleted from the buffer and the window can be opened up. The window size is granted at connection set-up and can be changed dynamically. 4.5 Keep Alive The POLL/SOLICITED STATUS exchange in addition to providing "out-of-band" ACK/NAK capability also serves as a kind of keep-alive function which helps in determining the loss of a transport path. This mechanism assists in the case of prolonged absence of data transfer. sidebottom Informational [Page 7] INTERNET-DRAFT Functional Description of SSCOP 4.6 Local Data Retrieval SSCOP can provide for SSCOP-User retrieval of unsent / unacknowledged data PDUs in the event of the loss of the transport path. This traffic could then be transferred to another transport path for delivery. 4.7 Connection Control Connection establishment or release services of SSCOP are served by a two message exchange. Establishment may be rejected by the peer SSCOP user. The POLL/SOLICITED STATUS exchange in addition to providing "out-of-band" ACK/NAK capability also serves as a kind of keep-alive function which helps in determining the loss of a transport path. 5. Acknowledgements The author would like to thank Lyndon Ong for his comments & suggestions 6. References [1] L.Ong, I.Rytina, "Architectural Framework for Signaling Transport" , February 1999, work in progress. [2] ITU-T Recommendation Q.2100, B-ISDN Signalling ATM Adaptation Layer (SAAL) Overview Description [3] ITU-T Recommendation Q.2110, "B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), July, 1994 [4] ITU-T Recommendation Q.2130, "B-ISDN Signalling ATM Adaptation Layer - Service Specific Coordination Function for support of signalling at the user-to-network interface (SSCF at UNI). [5] ITU-T Recommendation Q.2140, B-ISDN Signalling ATM Adaptation Layer - Service Specific Coordination Function or Signalling at the Network Node Interface (SSCF at NNI) [6] ITU-T Recommendation Q.2931, B-ISDN - Digital Subscriber Signalling System No. 2 (DSS2 - User network interface layer 3 specification for basic call/connection control) [7] ITU-T Recommendation Q.704 "Signalling Network Functions and Messages", March 1993 sidebottom Informational [Page 8] INTERNET-DRAFT Functional Description of SSCOP [8] T.Seth, A.Broscius, C.Huitema, H.Lin, "Performance Requirements for Signaling in Internet Telephony", , November 1998, work in progress Authors' Address Greg Sidebottom Nortel Networks 3685 Richmond Rd. Nepean, Ontario Canada K1Y 4H7 gregside@nortelnetworks.com sidebottom Informational [Page 9]