Internet Engineering Task Force INTERNET-DRAFT Author Transport Working Group Ian Rytina Category: Informational Ericsson February 1999 Expires: August 1999 Framework for Generic Common Signaling Transport Protocol < draft-rytina-sigtran-generic-framework-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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document outlines a possible generic framework for the Sigtran protocol. The intention is to define a framework for Sigtran which allows for all SCN protocols to be added as extensions to the base Sigtran protocol, without affecting the protocol itself. This will help progress the work in Sigtran, so that certain "key" SCN protocols could be defined in the first stage of the Working Group, and additional ones added at a later date, if and when required. Rytina Informational [Page 1] INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt 1. Introduction 1.1 Overview This document outlines a possible generic framework for the Sigtran protocol. The intention is to define a framework for Sigtran which allows for all SCN protocols to be added as extensions to the base Sigtran protocol, without affecting the protocol itself. This will mean that that certain "key" SCN protocols could be defined in the first stage of the Working Group, and additional ones added at a later date, if and when required. 1.2 Terminology The following general term is used in this document: Common Transport Protocol (CTP): This is a generic term used to describe the protocol developed by Sigtran. It is assumed to be an addition to the underlying transport protocol (TCP/UDP) to provide the performance required by the carried SCN protocol - for example CTP may be a protocol running over TCP or UDP. See also [1]. 1.3 Scope Signaling transport focuses on transparent transport of SCN signaling protocols over IP networks. The signaling transport protocol will be defined in such a way as to support encapsulation and carriage of a variety of application and call control protocols. For more information refer to [1]. It is the intention that CTP be designed in an open manner so that it can be integrated with multimedia frameworks such as H.323 and SIP, to provide transport of SCN protocols in such systems. 2. Protocol Framework Architecture 2.1 Generic Structure The difficulty with a working group that is defining a generic protocol to carry other protocols is that the set of protocols which are to be supported is potentially very large. Since there are many SCN protocols, each with different requirements, this is a task that extremely difficult and is likely to delay the work. A concept of a generic structure for the protocol is being proposed in order to put a framework in place so that a subset of "key" protocols can be worked on, while not precluding future work on other protocols. Essentially, the idea behind the generic structure is that all SCN protocols have some common basic requirements for transport, and some can be further broken down into groups of similar protocols. Rytina Informational [Page 2] INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt Figure 1 outlines the ideas behind a generic protocol structure for Sigtran. The structure consists of three types of module, arranged in a 1:n:m basis. +--------------+ | | | Module A | |(Generic Part)| | | +------|-------+ | | +--------------------+------+------------------+ | | | +--------|--------+ +-------|---------+ +-------|---------+ | | | |. . . .| | | Module B1 | | Module B2 | | Module Bn | |(Service Level 1)| |(Service Level 2)|. . . .|(Service Level n)| | | | | | | +-------|---------+ +-------|---------+. . . .+-------|---------+ | | | +-----+-------+ +-----+-------+ +-----+-------+ | | | | | | | | | +-|-+ +-|-+ +-|-+ +-|-+ +-|-+ +-|-+ +-|-+ +-|-+ +-|-+ |C11| |C12|. .|C1m| |C21| |C22|. .|C2m|. . . .|Cn1| |Cn2|. .|Cnm| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ Figure 1: Protocol Framework Modules The three modules can be described as follows :- Module A : This is the main Sigtran module, which specifies the base parts of CTP, valid for all SCN protocols being transported. The information carried could be, for example, SCN protocol identification indicator, input/output signaling addresses, message length, multiplexed message information, and message sequence number. There may also be a need for a "message type indicator", if it is decided that management messages are required for CTP (e.g. heartbeat, keepalive) to distinguish between those messages that are carrying the SCN native protocols and the CTP management messages. Module B : These are the modules describing each different "Service Level". Different SCN protocols may have different functional and performance requirements, but some could be grouped together into different functional/performance service levels. Rytina Informational [Page 3] INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt For example, possible different service levels could be (this is not intended to be a definitive list) :- SL1 SS7 applications on MTP3 (ISUP, SCCP) SL2 DSS1 applications (Q.931) SL3 Applications on SCCP (i.e. TCAP) SL4 Applications on TCAP (MAP, INAP, IS-41, etc.) SL5 Applications on MTP2 (MTP3) SLn . . . . . . . . . . . . . . . . . . Example information that could be contained in a Module B is whether TCP or UDP is used, retransmission timers for UDP, plus other relevant transport information. In some cases, it may also be possible to encapsulate different protocols in the same IP packet, provided that the service levels of these protocols are the same. Module C : These are the actual protocol modules, one for each of the protocols being defined to be carried by CTP, e.g. ANSI ISUP, ITU MTP3, etc., etc. Each module C would specify its own SCN protocol identification indicator (as described in module A), plus the service level (module B) being used by that specific protocol. Other information such as functions to be supported by the protocol, and possible interwork with other protocols may also be included. 2.2 Protocol Development The advantage of this system is that a common CTP can be defined, without the need to consider every protocol. One RFC could be written to describe the generic parts and framework of CTP (module A) and the different service level parts (modules B). This would be the main output of the Working Group. Internet Drafts could be submitted for each individual protocol (modules C), as required. These could be converted to individual RFCs per module C, or if this involves too much administration, be converted into a single RFC, which is designed to be easily extensible. 3. Acknowledgements The author would like to thank Lyndon Ong, Christian Groves and Mark Hollis for their valuable input. Rytina Informational [Page 4] INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt 4. References [1] L.Ong, I.Rytina :- Architectural Framework for Signaling Transport , February 1999, work in progress. Author's Address Ian Rytina, Ericsson Australia, 37/360 Elizabeth Street, Melbourne, Victoria 3000, Australia ian.rytina@ericsson.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. This Internet Draft expires in 6 months from February 1999. Rytina Informational [Page 5] INTERNET-DRAFT draft-rytina-sigtran-generic-framework-v00.txt