Internet DRAFT - draft-faynberg-telephone-sw-net
draft-faynberg-telephone-sw-net
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:51:58 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:32:00 GMT
ETag: "2e6fa7-5b98-350ea580"
Accept-Ranges: bytes
Content-Length: 23448
Connection: close
Content-Type: text/plain
Network Working Group I. Faynberg
Internet Draft M. Krishnaswamy
Expire in six months H. Lu
Bell Laboratories,
Lucent Technologies
A Proposal for Internet and Public Switched Telephone Networks
(PSTN) Internetworking
<draft-faynberg-telephone-sw-net-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 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 learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 1
2. Service Description . . . . . . . . . . . . . . . . 2
3. Scope of the Proposed Project . . . . . . . . . . . .3
3a. Intelligent Network . . . . . . . . . . . . . . . . .3
3b. Overall Architecture . . . . . . . . . . . . . . . . 5
3c. Interfaces Relevant to the Project . . . . . . . . . 5
3d. A Click-to-Dial Service Scenario . . . . . . . . . . 6
3e. On Carrying Out the Work. . . . . . . . . . . . . . .6
4. Security Considerations . . . . . . . . . . . . . . .7
5. References . . . . . . . . . . . . . . . . . . . . . 8
6. Authors' Address . . . . . . . . . . . . . . . . . . 8
7. Appendix (Figures A and B).................... . . . 9
1. Introduction
The purpose of this Internet Draft is to start discussion on the
issues involved in interconnecting Internet and Public Switched
Networks so as to provide more effective media than either
network type can do presently. Interworking of the Internet and
PSTNs, based on open well-defined interfaces, will promote
interoperability of both the networks and systems built by
different vendors.
This Internet Draft specifically proposes a type of
interconnection that involves only an Internet application, the
TCP/IP suite being the only transport means considered. Although
many such types of interconnections are possible, only one is
considered here--the one based on the architectural concept
(introduced later in this document) called the Intelligent
Network (IN). IN has been standardized internationally by the
International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) and is being widely implemented
in the telecommunications networks around the world.
Still, even when restricted to IN, several interconnection
choices can be made. Again, to narrow the subject of discussion,
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 1]
A Proposal for Internet and PSTN Internetworking March 1997
this proposal makes one choice. To this end, the document
outlines specific interfaces between Internet and IN and
proposes the method to carry out the work. The proposal makes it
clear which interfaces are to be standardized by IETF and which
are to be standardized by ITU-T; since both sets of interfaces
are mutually exclusive in that respect, there is only a minimal
need for coordination between the two bodies. The proposal
addresses the coordination issues.
The rest of this document is as follows:
Section 2 briefly describes the services offered to the end
user. It is the support of these services that necessitates the
proposed internetworking project.
Section 3 describes the scope of the proposed project by
introducing its overall architecture, identifying the interfaces
to be standardized, and suggesting the coordination steps that
need to be taken to ensure consistent results of standardization
should it be undertaken by both IETF and ITU.
Sections 4, 5, and 6 respectively address security
considerations, supply references, and provide the authors
address, as required by [1].
Section 7 is the Appendix, which contains the figures (available
only in the PostScript format).
2. Service Description
The common denominator of the services introduced in this
section is bringing telephone services (provided by PSTNs) to
Internet users. Successful interworking of the Internet and
Public Switched Telephone Network (PSTN) should enable
integration of PSTN services (e.g., a telephone call) with those
offered by the Internet through the World-Wide Web. Examples of
such services are Click-to-Dial, Click-to-Fax, Click-to-Fax-Back,
and Voice access to content, and they can be briefly described as follows:
With the Click-to-Dial service, a Web user can initiate
a PSTN call by clicking a button during a Web session.
Such a call can be either incoming or outgoing. (An
example of the former is when a user, while browsing
through a catalogue, clicks the button inviting a sales
representative to call him or her.)
With the Click-to-Fax service, a Web user can send
a fax by clicking a button during a Web session.
With the Click-to-Fax-Back service, a Web user can request
(and subsequently receive) a fax by clicking a button
during a Web session.
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 2]
A Proposal for Internet and PSTN Internetworking March 1997
With the Voice-access-to-content service, a Web user can
have access to the Web content by telephone. The content
is converted to speech and transmitted to the user on a
telephone line.
3. Scope of the Proposed Project
A somewhat general view of the proposed project is presented in
Figure A of the Appendix. The figure distinguishes the two types
of end-users: 1) the Web users, whose PCs (or other Internet
access devices) are connected to the Internet, and 2) the
telephone users, whose telephones or fax machines are connected
to PSTNs. In this context, the proposed internetworking involves
interconnection of Internet service providers and network
operators (who own PSTNs).
In order to proceed with a more specific definition, this
document introduces the concept of Intelligent Network (IN) in
the next subsection. The subsections that follow respectively
outline the overall architecture, identify the interfaces
relevant to the project, demonstrate the involvement of the
interfaces in the function of the Click-to-Dial service, and
propose the steps necessary for carrying out the work.
3a. Intelligent Network (IN)
IN ([2], [3]) is an architectural concept that provides for the
real-time execution of network services and customer
applications in a distributed environment consisting of
interconnected computers and switching systems. Also included in
the scope of IN are systems and technologies required for the
creation and management of services in this distributed
environment.
In PSTNs, user's telephone terminals and fax machines are
connected to telephone switches. The switches (which can be
Central Offices--for wireline communications and Mobile
Switching Centers (MSCs)--for wireless communications) are specialized
computers engineered for provision of services to the users. The
switches themselves are interconnected in two ways: 1) through
trunks on which the voice is carried and 2) through a
specialized fault-tolerant data communications network, which is
(principally) used for call setup and maintenance. This network
is called (after the ITU-T standard protocol suite that it uses)
Signalling System No. 7 (SS7). In addition, the switches are
connected to general purpose computers that support specialized
applications (called Operations Systems) whose role includes
network management, administrative functions (e.g., billing),
maintenance, etc. Operation systems are not connected to the
switches through the SS7 network, which is, again, engineered
only for set-up and real time maintenance of calls. In most
cases, X.25 protocol is used for communications between
operations systems and switches.
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 3]
A Proposal for Internet and PSTN Internetworking March 1997
Even a simple two-party call in most cases involves several
switches, which may also be located in different PSTNs. To this
end, the switches alone comprise a complex distributed
processing environment. As far as the end users are concerned,
the switches are ultimately responsible for delivering
telecommunications services. Certain elementary services (such
as provision of the dial tone, ringing the called line, and
establishing a connection between two users) are called basic
services, and all switches can presently cooperate in delivering
them to end users.
In addition, a multitude of services (such as Freephone [a.k.a.
800 number in North America], Conference Calling, Call
Forwarding, and many others) require much more than basic call
processing. Such services are called Supplementary Services, and
their implementation requires that specialized applications
(called Service Logic) be developed. Developing switch-based
service logic for each supplementary service would be an
extremely expensive (if at all possible) task, which--in the
presence of multiple switch vendors--would also require an
extensive standardization effort.
The IN architecture is the alternative which, in a nutshell,
postulates using a network-wide server (called Service Control
Function [SCF]). The SCF executes service logic and instructs
the switches on how to complete the call. A switch is involved
only in executing the basic call process, which is interrupted
(at standardized breakpoints called triggers) when specialized
service logic needs be executed. On encountering such a
breakpoint, the switch issues a query to the SCF and waits for
its instruction. In addition (and this is essential for
supporting the services described in section 2), the SCF may
initiate a call on its own by instructing switches to establish
necessary connections among themselves and to the call parties.
Physically, the SCF may be located in either stand-alone general
purpose computers called Service Control Points (SCPs) or
specialized pieces of equipment called Service Nodes (SNs). In
addition to executing service logic, a service node can perform
certain switching functions (such as bridging of calls)as well
as a set of specialized functions (such as playing
announcements, voice recognition and text-to-speech conversion).
An important distinction between an SCP and SN is that the
former is connected to switches via the SS7 network while the
latter communicates with the switch via Integrated Services
Digital Network (ISDN) Primary or Basic Rate Interfaces (PRI or
BRI), which combine both the signaling and voice paths.
With the present state of IN standardization, in principle,
either an SCP or SN could be connected to an Internet server in
order to support the services outlined in section two. To
further narrow the scope of work so as to produce tangible
results as soon as possible, the proposed project specifically
addresses only interconnection between a server and SN.
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 4]
A Proposal for Internet and PSTN Internetworking March 1997
Within the IN architecture, the relevant administration of the
network entities (i.e., setting the triggers in the switches,
transferring externally developed service logic to SCPs and SNs,
and maintaining the network databases with the customer-related
data) is performed by a specialize Operation System called
Service Management System (SMS).
3b. Overall Architecture
Figure B demonstrates the overall architecture addressed by the
proposed project. This figure may also serve as an illustration
to the IN discussion of the previous subsection.
The PSTN users are depicted connected to both the central office
via wireline and mobile switching center via wireless
communications. The IN entities that contain the Service Control
Function (i.e., the SN and SCP) are shown with their respective
interfaces to, first of all, the switches. Specifically, the
ISDN-based interfaces from the SN to the MSC and center office
are respectively marked I and C; the SS7-based interfaces from
the SCP to the MSC and center office are respectively marked F
and G. (The latter two interfaces are depicted with the dotted
line because they are not within the scope of the proposed
project). Finally, the SMS is depicted together with its
respective interfaces to the SN (D) and SCP (H). (Again, the
interface H is depicted with the dotted line because it is not
within the scope of the project.)
On the Internet side, Figure B exhibits a Web user connected to
the Web server. As far as the proposed project is concerned, the
server has two interfaces: interface A to the SN and interface B
to the SMS. (As before, a feasible, but not considered within
the scope of the project, interface E to the SCP is depicted
using the dotted line.) It is proposed that the A interface be
based on TCP/IP, and the B interface, on Simple Network
Management Protocol (SNMP).
3c. Interfaces Relevant to the Project
With the present proposal, the interfaces that are relevant to
the project are A, B, D, I, and C.
The interfaces between the SN and switches (interfaces I and C),
as well as the interface between the SN and SMS have been
studied in ITU-T Study Group 11; the interfaces between the Web
server and SN (interface A) and Web Server and SMS (interface B)
are proposed for standardization within the IETF.
The following subsection presents an example Click-to-Dial
service scenario, which should give an idea of how the
interfaces are used.
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 5]
A Proposal for Internet and PSTN Internetworking March 1997
3d. A Click-To-Dial Service Scenario
For the purposes of this discussion, it is assumed that the Web
user exemplified here has telephone access while using the Web
(this can be achieved, for example, by having an ISDN
connection). We find this Web user in the act of browsing
through a sales catalogue and deciding to speak to a sales
representative.
When the Web user clicks a button inviting a telephone call from
the sales office, the Web server sends a message to the SN over
the A interface, thus crossing the Internet-to-PSTN boundary. By
matching the information received from the Web server with the
user profile that had been previously loaded and activated by
the SMS over the D interface, the SN recognizes the signal.
At this point, the SN invokes service logic as indicated in the
profile. The execution of this logic selects an appropriate
sales person to call based on the time of the day. It is 8 P.M.
in New York where the Web user is located, and the New York
sales office has been closed. But the San Francisco office is
still open, and so the SN selects an appropriate central office,
establishes the connection (the interface C) to this central
office, verifies that there is at least one sales agent line
that is free, instructs the switch to establish a two-party call
between the sales agent and the Web user, and--quite
importantly--instructs the switch to charge the call to the Web
content provider.
3e. On Carrying Out the Work
The interfaces relevant to the project fall into two classes:
1) the A and B interfaces, and
2) the C, D, and I interfaces.
ITU-T SG 11 will continue the work on the second class of the
interfaces. It is proposed that the IETF start the work on the
first class.
Naturally, coordination would be required to ensure that the
data exchanged over the A and B interfaces are consistent with
those exchanged over the rest of the interfaces. Furthermore,
the amount and rate of delivery of data over any of the
interfaces involved should be consistent with what both PSTNs
and the Internet may support without jeopardizing the overall
network performance of either network. The security
considerations are discussed in a separate section of this
document as required by [1].
It is proposed that the coordination be achieved by exchanging
information between the IETF and ITU-T on the progress of the
standardization efforts in the respective organizations. The
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 6]
A Proposal for Internet and PSTN Internetworking March 1997
authors of this proposal (who participate in both organizations)
volunteer to ensure that such information be exchanged properly
and efficiently.
The authors also volunteer to deliver a tutorial on the
Intelligent Network standards to members of the IETF who may be
interested in participating in the proposed project.
4. Security Considerations
Internetworking of the Internet and PSTN necessitates the
introduction of new interfaces, i.e., the A and B interfaces
described in the previous sections. To ensure that their use
does not put the networks at additional security risk, these
interfaces should be designed to meet the basic security
requirements such as follows:
+Peer entity authentication to allow a communicating entity
to prove its identity to another in the network. Two types of
peers should be recognized for the purposes of this project:
end-user and the Web server, and Web server and SN.
Between the end-user and Web server the authentication could be
accomplished by means of the user name and password combination.
In addition, encrypted communications could be used in this case.
Same could be used between the Web server and SN, but it is proposed
that additional security be accomplished by replicating a part of the
server's data base relevant to the business providing the service.
+Non-repudiation to account for all operations in case of
doubt or dispute. This could be achieved by logging all the
information pertinent to the Web transaction. In addition, the
PSTN network will maintain its own account of the transaction for
generating bills.
+Confidentiality to avoid disclosure of information without
the permission of its owner. Although this is an essential
requirement, it is not particular to the proposed project.
+End-user profile verification to verify if the end user is
authorised to use a service.
Of course, in the course of the project execution, additional
requirements are likely to arise and many more specific security work
items are likely to be proposed and implemented.
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 7]
A Proposal for Internet and PSTN Internetworking March 1997
5. References
[1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993
[2] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah,
"The Intelligent Network Standards, their Application to
Services". McGraw-Hill, 1996.
6. Authors' Address
Igor Faynberg
E-mail: faynberg@bell-labs.com
Telephone: +1-908-949-0137
Fax: +1-908-949-1196
Bell Laboratories
Room 4K-309
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Murali Krishnaswamy
E-mail: murali@lucent.com
Telephone: +1-908-949-3611
Fax: +1-908-949-3210
Bell Laboratories
Room 2G-527a
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
Hui-Lan Lu
E-mail: hui-lan.lu@bell-labs.com
Telephone: +1-908-949-0321
Fax: +1-908-949-1196
Bell Laboratories
Room 4K-309
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 8]
A Proposal for Internet and PSTN Internetworking March 1997
7. Appendix (Figures A and B)
FIGURE A:
O End Users (PC Access) O End Users (Voice Access)
| |
| |
^ ^
--|--------------------------------------|----
| |
| Content Service Providers | Network Operators
\ / \ /
============================= =======================================
|| World Wide Web/Internet || || Public Switched Telephone Network ||
============================= =======================================
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 9]
A Proposal for Internet and PSTN Internetworking March 1997
Figure B:
Web
User
____________
O -------------------------- | Internet |------------------------
------------ |
|
|
---------------- -------------- ---------------
| Service Node | D | Service | B | Web Server |
| (SN) |------------| Management |------------------| |
| | |System (SMS)| | |
| | -------------- | |
| | A . | |
| |--------------------------------------------| |
---------------- . -------------
| | . .
| I | C . H . E
| | ........................ .
---------- -------- G --------
|Mobile | |Central|-----------------------------------------|Service|
|Switching| |Office | |Control|
| Center | --------- F |Point |
| |-----|---------------------------------------------| |
----------- | | (SCP) |
| | ---------
| |
O O
Mobile Wireline PSTN
Users Users
I. Faynberg, M. Krishnaswamy, and H. Lu [Page 10]
