Internet Draft D. Shrader draft-shrader-spirits-arch-00.txt Master Consultant February 2000 Expires July 2000 Framework Architecture for Service in the PSTN/IN Requesting Internet Service (SPIRITS) 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 defines an architecture framework and functional requirements for Service in the PSTN/IN Requesting Internet Service (SPIRITS). The framework describes relationships between functional entities for interactions between the PSTN and SPIRITS Server and provides requirements for the SPIRITS protocol. This document is submitted to the IETF SPIRITS working group for discussion and comment. Discussion on this topic should be sent to the SPIRITS mailing list (spirits@lists.research.bell-labs.com). 1. Introduction This document defines an architecture framework and functional requirements for Service in the PSTN/IN Requesting Internet Service. The architecture addresses how services supported by IP network entities can be started from IN (Intelligent Network) can request actions to be carried out in the IP network in response to events occurring in the PSTN/IN. The architecture and protocol should support secure transport of IN requests for actions, as well as plain event notifications and parameters from the PSTN/IN to the IP network, and optional responses from the IP network back to the PSTN/IN. Based on this architecture, basic requirements for the methodology for constructing the building blocks of the SPIRITS protocol. The rest of this Internet Draft is as follows: Section II describes the functional architecture; Section III describes applicable physical architectures; Section IV provides requirements for the protocol to be defined; Section V addresses management of the SPIRITS system; Section VI contains security considerations; Section VII contains abbreviations Section VIII contains the acknowledgements; Section IX contains references; and 2. Functional Architecture The SPIRITS functional architecture includes three potentially independent entities: - the PSTN/IN requesting system - the SPIRITS client - the SPIRITS server ------------ ------ | PSTN/IN | --------- --------- ------ | User |-----| Requesting |-----| SPIRITS |-----| SPIRITS |-----| Opt. | ------ | System | | Client | | Server | | User | ------------- --------- --------- ------ The following elements compose the SPIRITS functional architecture: User - the originating call participant on a call that is served by the PSTN system. PSTN/IN Requesting System - the element (or network of elements) involved in detecting that SPIRITS service invocation is required. SPIRITS Client - the entity that notifies an IP server or requests some actions to be performed in the IP network. SPIRITS Server - the entity that receives notifications or requests and returns optional responses. Opt. User - a user that is optionally consulted by the SPIRITS server in the process or handling the request The interactions between the SPIRITS Client and the SPIRITS Server is the subject of the SPIRITS protocol. The other interfaces are assumed but not specifically addressed by the SPIRITS protocol. 3. Physical Architecture The SPIRITS functional model is flexible to allow for application of the SPIRITS mechanism to be used to support the many different forms of PSTN/IN systems currently in use. As such, several physical architectures are presented that SPIRITS is intended to support. The following architectures are defined: 1. PSTN/IN based on Intelligent Network The SPIRITS Client can be collocated with the IN Service Switching Point, IN Services Node, or IN Service Control Point. 2. Wireless Intelligent Network The SPIRITS Client can be collocated with the WIN Service Control Point, HLR, VLR, or MSC. 3. Private Enterprise System The Private Enterprise System can be a SPIRITS Client. 4. Decomposed system utilizing Megaco/H.248 The Media Gateway Controller can perform SPIRITS Client functions directly or via an IN Service Control Point. 5. H.323 System The H.323 Gatekeeper can perform SPIRITS Client functions directly. 6. SIP System The SIP Server can perform SPIRITS Client functionality (and SPIRITS Server functionality when a call processing script is involved?) Figures for these architectures to be provided in an Appendix. 4. Protocol Requirements My first thoughts on protocol requirements... The SPIRITS protocol SHOULD support forwarding to subsequent servers via proxy. The SPIRITS protocol SHOULD support forwarding to subsequent servers via redirect. The SPIRITS protocol MUST support dynamic arming of events. The SPIRITS protocol SHOULD support requests for subsequent information from the originating user. The SPIRITS protocol MUST be extensible. 5. Management To be provided. 6. Security Considerations To be provided. 7. Abbreviations PSTN Public Switched Telephone Network IN Intelligent Network IP Internet Protocol SPIRITS Service in the PSTN/IN Requesting Internet Service HLR Home Location Register VLR Visited Location Register MSC Mobile Switching Center 8. Acknowledgements To be provided. 9. References [1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services," McGraw-Hill, 1997. [2] I. Faynberg, et al., "Toward Definition of the Protocol for PSTN- initiated Services Supported by PSTN/Internet Interworking," draft-faynberg- spirits-protocol-00.txt, expires April 2000. 10. Appendix The following figure is taken directly from Faynberg draft. It needs to be modified to reflect the text in Section 3 and expanded to include additional figures for other physical architecture types. Figure 1: SPIRITS Physical Architecture ------------------------- | PC or Network Appliance | ------------------------- | ------------ O -------------------------- | Internet |----------------------- ------------ | | ---------------- -------------- --------------- | Service Node | D | Service | B | SPIRITS | | (SN) |------------| Management |------------------| Server | | | |System (SMS)| | | | SPIRITS | ------------ | | | Client | : A | | |______________|-------[ IP Network]------------------------|_____________| | : | | C : H E [IP Network] | ........................ | -------- G -------- |Central|-----------------------------------------|Service| |Office | |Control| --------- |Point | | (SCP) | | | |SPIRITS| |CLIENT | --------- Author's Addresses David Shrader Master Consultant, Inc. P.O. Box 30237 Fort Lauderdale, FL 33303-0237 USA E-mail: DShrader@EyeForTheFuture.com Telephone: +1 954 525 9009