INTERNET-DRAFT
Networking Working Group L. Conroy
Internet Draft M. Lautenbacher,
Expires on 7 January 1998 R. Scholl
Roke Manor Research
Siemens AG
Analysis of Services and Interfaces used when Interworking
Between the Internet and the Intelligent Network (I.N.)
<draft-conroy-interfaces-in-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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
The plethora of networks comprising the Internet have been getting
bigger and faster in the past at a tremendous rate. In the future,
to address all of the current and future pervasive services, the
Internet will also have to get better, i.e. it will need more
intelligence created by clever software deployed throughout the
network.
This Internet Draft advances the discussion on the issues
involved in interconnecting the Internet and Public Switched
Telephone Networks (PSTNs), focusing on potential interfaces between
Internet-based devices and Intelligent Network (I.N.) devices.
Services based on the interplay of PSTN / I.N. and the Internet are
discussed and classified, and an outline of a protocol architecture
for the interface between the Internet and the Intelligent Network is
given.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 1]
Service and Interface Analysis with Internet/I.N. Interworking
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 2
1.2. Context . . . . . . . . . . . . . . . . . . . . . . 3
2. Intelligent Network Entities and their Roles . . . . 3
3. Services Offered over I.N./Internet Interface. . . . 6
4. Interfaces and Interaction . . . . . . . . . . . . . 8
5. Protocol Architecture . . . . . . . . . . . . . . . 9
6. Security Considerations. . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . 14
8. Authors' Address . . . . . . . . . . . . . . . . . . 15
Appendix: PSTN-101 . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
This document carries on the work started in an earlier Internet Draft
[1] to contribute to the task of developing Internet protocols that
can engender services to be provided between Public Switched
Telecommunications Network (PSTN) terminals, using Intelligent Network
(I.N.) entities to control those services within the PSTN.
This draft explores potential interfaces between Internet-based
devices and Intelligent Network (I.N.) devices. Due to the large
number of possible interactions between Internet and PSTN-connected
devices, it is proposed that the set of services to be provided and
the kind of interaction available be limited in a first stage, so
making the task of defining a particular Interface and the behavioural
repertoire of entities corresponding over it manageable.
The document provides an initial classification of services proposed
in the earlier Internet Draft [1]. This classification is used to
highlight the kinds of behaviour expected of the corresponding
entities, and is not intended as an exhaustive analysis of the
services themselves. From this classification the kinds of interaction
across the Internet/I.N. boundary are considered, focusing on the
roles taken by the correspondents. In turn, the kinds of interaction
involved are used to describe the protocols that could be used to
carry messages implied by these interactions, and the way in which
these protocols work together.
Security issues raised by Internet/I.N. interaction are of particular
concern and must be addressed before any such interface will be
acceptable. This is a significant task, but this document lists some
of the concerns that must be resolved.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 2]
Service and Interface Analysis with Internet/I.N. Interworking
1.2. Context
This draft is NOT intended to define standards that will be
implemented inside the Public Switched Telephone Network (PSTN). The
IETF is perceived as being the centre for expertise on the operation
of the Internet, and the behaviours described here are used to help
clarify the kinds of interaction expected and so the protocols to be
carried over the Internet. Implementation of the physical interface
between the Internet and the Intelligent Network (I.N.) is not
addressed here, as it will, of necessity, be the province of the
International Telecommunications Union (ITU) Standards Group
responsible for Intelligent Network Recommendations (SG11) and the
regional telecommunications standardisation bodies (e.g. ANSI and
ETSI).
Definition of the logical interface between the Internet and the I.N.
will have to be the result of co-operation between the ITU and the
IETF. By restricting the kinds of services offered across the
interface and the patterns of interaction between Internet and
Intelligent Network entities, the behaviours and protocols implied can
be limited. This has the advantage of reducing the work needed to
provide a definition for an "Initial Protocol".
Preparatory work during the first phase will give a framework for the
services to be provided and for future enhancements to the protocols
used between the Internet and Intelligent Network. This work is
important as the services offered across the interface will be
"hybrids". They will be delivered by a combination of Internet
Services and I.N. Services. If a framework for the services and
behaviours expected across the Interface is created, then the work of
specifying the I.N. Services needed can be decoupled from that implied
by the Internet protocols, allowing the appropriate ITU Study Group to
carry it out. This in turn will ensure that Telecommunications
Equipment Manufacturers can work with clear service definitions in
order to provide interoperating equipment and similar services to
their customers. It also means that Internet based devices can be
provided with a protocol set and expected behaviour to allow them to
interact with the I.N. (and thus the PSTN "beyond") in a controlled
manner, without having to understand the details of I.N. operation.
2. Intelligent Network Entities and their Roles
This section mentions the roles carried out by components of the
Intelligent Network, at least as far as required for the provision of
the services described next. For an introduction to the operation of
the I.N. and the way that services are provided using it on the PSTN,
see [2] or [3], whilst the set of recommendations defining the
operation of the Intelligent Network are in [4]. A brief introduction
is also given in [1], with another in the appendix to this draft.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 3]
Service and Interface Analysis with Internet/I.N. Interworking
Services provided on the PSTN with I.N. components take the idea of a
simple call between two PSTN terminals (such as telephones or telefax
machines) beyond the basic task of connecting them together through
the network. Each terminal will be connected to a Central Office (or
Telephone Exchange). The basic call consists of a user opening a
channel to the Central Office, passing a number that is to be
interpreted as the address of the terminal with which they want to
make contact, and the processor in that Central Office forming a route
through the network towards the destination, in collaboration with the
"cloud" of its peer Central Offices. The destination terminal will be
alerted to the requested call, the called user will "pick up the
phone", and the correspondents can then communicate. From the
perspective of the Intelligent Network, this is a basic call service,
and is carried out by a set of functional entities collectively called
the Call Control Function (CCF), with the Call Control Agent Function
(CCAF) at either "end" of the route dealing with decoding the calling
user's dialled number and managing the status of the terminals.
The I.N. approach adds several functional entities to this (see
diagrams in the appendix), allowing extra services to be provided in a
flexible manner. To the CCF is added an extra set of functionality
called the Service Switching Function (SSF). This can be configured to
detect particular events (such as a certain pattern of digits having
been dialled). It can instruct the CCF to manipulate the state of a
call so that it can, for example, make a temporary connection to
another terminal and then clear the connection without closing the
call, or drop the call immediately, or dial out to another number from
the one dialled by the user.
Another entity has been added, called the Service Control Function, or
SCF. As the name suggests, this can be given "executive control" of
the call, and can pass instructions to the SSF telling it how to
handle the request. With most services, the SSF "triggers" on
detecting a particular event like a pattern of digits dialled, and
will suspend the call whilst it passes control to the SCF by sending
it a request for instructions. This will invoke a program on the SCF
that takes the request for instructions from the SSF, operates on the
parameters passed (such as the digits dialled), and eventually tells
the SSF to continue execution, optionally passing parameters back to
it for it to use in processing the call (such as the number to use as
the destination for this call).
Where further information is required to clarify the call request
(such as account codes or PINs) the SCF can instruct the SSF to
connect the user, temporarily, to another entity called a Specialised
Resource Function (SRF). This component holds units that can decode
extra digits dialled by the user in response to announcement or prompt
messages it sends to them under command of the SCF. Once this has been
done, the SCF can ask for a report on the digits dialled, and when a
message holding this has been returned to it, the SCF can instruct the
L. Conroy, M. Lautenbacher, and R. Scholl [Page 4]
Service and Interface Analysis with Internet/I.N. Interworking
SSF to remove the temporary connection to the SRF and can continue its
deliberations on the call request (for example by checking the
validity of the account code and PIN by querying an associated entity
called a Service Data Function, or SDF). When the SCF has decided on
the next course of action, it will pass back instructions to the SSF
to progress the call.
Note that the SCF operates by receiving request messages from the SSF
and sending messages back to it. It has no direct contact with the
user (or the digits they dial) and is a "pure" processor; it is a
computer running specialised programs, but these interact with the
other components via messages rather than by interpreting the user's
requests directly. It always uses the SSF or the SRF as "middlemen"
when interaction with a user is needed.
In general, I.N. services can be modelled as having a request phase
(where digits are used both to select the request and as parameters to
that request), optionally an extra parameter phase to specialise the
request or to validate the user, and an implementation phase during
which the service is performed as requested. By breaking down a call
into these different sub-transactions, a fine degree of control can be
exercised, and a wide range of extra services can be provided that
range from Freephone or Premium Rate calls to Personal Number or Wake
Up calls.
The Intelligent Network approach has proved successful in that the
tasks of collecting the requests are separated from those of exerting
executive control and implementing any eventual routing through the
network. In the traditional Central Office, all of these aspects are
combined, and providing services on every Central Office in a PSTN can
prove unworkably cumbersome. From the perspective of the Internet, it
could be said that the Intelligent Network is "services done
properly".
When looking at services that are carried over the PSTN but are
requested from the Internet, however, the relationships between the
users and the entities fulfilling their requests are somewhat
different. For example, the request parameters are not restricted to
strings of digits, and the way in which the requests are generated
(for example, by submitting a form to a web server) is quite
different. Instead of collecting the parameters in a sequence of
commanded interactions between an SRF and the user making the request,
the request can be built up on the Internet, with the complete request
being sent to the Intelligent Network "en bloc". There is no
interaction between the SSF and the requesting device, with all
instructions "coming down" from the entity running the service. As
will be seen, there IS a role for the SRF in one category of services
requested from the Internet, but its role is restricted to transcoding
of data rather than collecting request parameters as well.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 5]
Service and Interface Analysis with Internet/I.N. Interworking
3. Services Offered over I.N./Internet Interface
There is a wide range of services that could be provided by
collaboration between the Internet and the Intelligent Network.
Several such services were mentioned in an earlier Internet Draft [1].
They are analysed here, along with an initial attempt at categorising
them.
The first of these services was called "Click to Dial". The premise is
that a user has (somehow) generated a request at an Internet-based
server, asking for a telephone call to be placed between two terminals
connected to the PSTN. This request is sent from the Internet server
to the I.N. system, and that equipment instructs the Central Offices
to place the call. From the Internet perspective, the request has been
made; the detection and implementation of that request are carried out
solely in the Intelligent Network.
The particular scenario chosen was an example of a Web-Activated
Callback Service. The user selects a page on the Web provided by a
company, fills in a form to indicate the phone number of a telephone
at their location, and submits this to a Web server. The form is
processed, a request is constructed and sent to the Intelligent
Network, and this provides a telecommunications service, selecting a
free agent and making a call from that agent to the customer supplied
phone number. Note that "Click to Dial" is a slight misnomer, as the
service provided is a call back, and there is no speech data sent
between the Internet and the Intelligent Network.
The next service was called "Click to Fax". The premise here is that
an Internet-connected user has some data that they would like
converted into a fax and sent to a telefax machine (on the PSTN). This
service is more involved than Click to Dial, as it requires data to be
collected from the Internet-connected user, together with the fax
number of the intended destination. The request and the data to be
sent are passed to the I.N. system, and this sets about converting the
data into a form suitable for sending as a fax, makes the call to the
destination telefax machine, and sends the generated facsimile to it.
Another "Fax related" service mentioned was called "Click to Fax
Back". The premise in this case is that an Internet connected user
generates a request including the fax number of the machine to which
they would like information to be sent, and that, together with an
indication of the information they would like, is constructed into a
request that is sent to the Intelligent Network. This will use the
information reference passed in the request to select a particular
document, will convert this as needed into a form suitable for sending
as a fax, and will then arrange for a call to be made to the
customer's telefax machine, sending the information they requested to
it. Unlike the Click to Fax service, this one involves (on the
Internet side) just sending a request; no data is sent to the
Intelligent Network.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 6]
Service and Interface Analysis with Internet/I.N. Interworking
However, there is an "operational" problem here. The Internet
generated request will have to contain a reference to the information
(held in the I.N. or the PSTN) to be "faxed back". Ensuring that the
reference passed in the request is valid, particularly if that
reference is embedded in a Web page, may prove difficult.
The last service mentioned was called "Voice Access to Content". This
is designed to allow a customer to have some subset of Web page
content delivered to them in speech form, via their telephone (on the
PSTN). It will require that the person making the request has some way
of identifying the phone number of the telephone to which they want
the speech version of the information to be sent, along with data
holding the web content to be processed. From the perspective of the
Internet, this service is similar to the "Click to Fax" service
mentioned earlier. The differences lie in the way that the Intelligent
Network treats the data it is passed.
Although not mentioned in these descriptions, any "production quality"
service will ensure that the requesting entity be kept informed of the
status of their request. The implication here is that there would be
at least an acknowledgement sent back from the I.N. to the
Internet-connected device that made the request of the Intelligent
Network. One option is for this to be arranged using a
connection-oriented transaction (using TCP to deal with the
request/response pair in the same way as version 1.0 of the HyperText
Transfer Protocol, or HTTP [5]).
There are drawbacks with the simple TCP-based approach, however. The
TCP connection setup and tear-down process takes time, and opening and
closing a TCP connection for each request can limit performance whilst
consuming bandwidth. A similar consideration was made when work began
on enhancements to HTTP, with the decision being taken to "reuse" the
TCP connection for subsequent requests in later versions of the
protocol. In this case, however, the rate of requests that are likely
to be carried over the boundary between the Internet and the I.N. is
lower, so this may not become a limiting factor. Overall, it seems at
least a valid choice.
Of the services described, there are some implications on the
configuration of the I.N. components. For example, the "Click to Fax"
service requires equipment to convert the passed data into a format
suitable for sending as a telefax, along with a unit that can engage
in a fax call.
Similarly, the "Voice Access to Content" service needs specialised
text to speech equipment within the Intelligent Network. In both cases
it is assumed that this specialised equipment is available; otherwise
it is not possible to provide the services.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 7]
Service and Interface Analysis with Internet/I.N. Interworking
Generalising from the individual services, there are some common
features that may be used to classify them. For example, in both the
"Click to Dial" and the "Click to Fax Back" service the Intelliligent
Network receives a request with two service parameters; the phone or
fax number to be used as the destination of a PSTN call it is to
arrange, along with an "information reference" to show the topic in
which the customer was interested. In some variants of these services
there might be another parameter indicating the location of the
company providing the information (akin to the xxyyzzz in a
1-800-xxy-yzzz number) or, potentially, the location of the "faxback"
information store.
In the case of the "Click to Fax" and "Voice Access to Content"
services, a request is sent to the I.N. from the Internet with
a parameter giving the phone or fax number to be used as destination
for the requested call. In addition, however, a component of the I.N.
is performing a transcoding of data that is also sent from the
Internet; the I.N. converts the data into a different form and sends
it to a different kind of PSTN terminal, but the overall process is
similar. The essential difference between these services and the
others is that, in this case a package of data must be sent from the
Internet along with the request, whilst in the case of the "Click to
Fax Back" and "Click to Dial" services, only the request is sent; in
effect, it contains control information only.
The services described here (and a number of others that involve
delivering I.N. services initiated from the Internet) fall into the
categories of "control interaction only", or "data transcoding"
services. Note that these two categories both require discrete
messages to be sent to and from the Intelligent Network. Any services
involving speech or a continuing data stream being passed across the
boundary are outside the scope of this work, and would form yet
another category of services.
4. Interfaces and Interaction
As mentioned above, there are potentially two separate information
exchanges between the Internet and the Intelligent Network. The first
of these is the initial request with its needed parameters, sent from
an Internet device to the Intelligent Network. The second is any data
that is to be processed within the I.N. and so is also passed to it
from the Internet.
The Service Node consists of an implementation of several Intelligent
Network functional entities tied together in a particular configuration
(see, for example ITU Q.1215 for details of some of the options). It
contains equipment providing the Service Control Function, units acting
as the Service Data Function, an embedded Switch providing the Service
Switching Function (for the local SCF only), and a set of auxiliary
equipments that provide the Specialised Resource Function.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 8]
Service and Interface Analysis with Internet/I.N. Interworking
There are very good reasons for defining a Service Node as the
Intelligent Network system that interacts with Internet devices (see
section on Security), and this draft assumes that a Service Node is
used rather than any other physical configuration of the Intelligent
Network.
If a Service Node is to be dedicated to interaction with the Internet,
then it is likely that the Specialised Resources it contains would be
quite different from those installed in other nodes. The two
"transcoder" resources needed for the "Click to Fax" and "Voice Access
to Content" services are unlikely to be required in services provided
solely on the PSTN (with no Internet involvement).
The kinds of information flowing between the Internet and the Service
Node might also reflect different destinations. On the PSTN, the SCF
receives requests (and request parameters) from the SSF. It may also
receive extra parameters from the SRF. However, the reason that
requests originate at the SSF is that the SSF has a "direct"
connection to the user's data stream, whilst the SCF doesn't.
Similarly, the SRF can be connected to the user's data stream, so it
can prompt and collect digits to be used as request parameters.
The situation is somewhat different where requests are generated and
delivered from the Internet. It is possible to construct a message to
be sent to the Service Node including all information needed by its
SCF, encoded into a format that is convenient to that SCF. At least
conceptually, this could be modelled as being sent directly to the
SCF, even if (in practice) it is handled in a different way.
Similarly, any response to the request will appear to be dispatched
from this entity back to the Internet.
The data that may be associated with a request, however, is almost
certain to be dealt with by the Specialised Resources. There is no
need for it to be passed "onwards" from the Service Node, nor for it
to be passed to any other components within the Service Node.
The nett result of this is that there could be considered to be two
destinations within the Service Node that receive information from the
Internet; one of them receives the requests and service parameters,
whilst the other one deals with any data that is processed as part of
the service. The Interface between the Service Node and the Internet
actually consists of two sub-interfaces, each with its own destination
logical end node.
5. Protocol Architecture
This section covers the kind of protocols to be used across the
interface between the Internet and Intelligent Network. As yet, the
work on provision of services across this interface has just started.
The details of the protocol messages to be exchanged require
refinement.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 9]
Service and Interface Analysis with Internet/I.N. Interworking
However, it is possible to consider what the protocols have to do and
so how the protocols work. The entities that will interact to provide
a service over the PSTN have been introduced already. This section is
intended to make some initial choices on the way that messages can be
sent between them across the Internet/I.N. boundary. As mentioned in
the separate section on Security Considerations (as required in [6]),
there is a need for a protected link between the Internet-based device
making a request and the Service Node. The protocols needed to ensure
this protection are not covered here; further work is needed on this
topic before provision of any Internet requested service will be
acceptable to some Network Operators (and Governments)and for now it
is assumed that such a link has been set up before the message
exchanges mentioned here are started.
As already suggested, there are two distinct forms of message
exchange. The first one is used to pass the service request, along
with the parameters needed for the particular service being requested.
It will also be used to pass responses back from the Intelligent
Network to the requesting Internet-connected device. This will be
needed for all services being requested across the boundary.
The second kind of transfer is needed for a category of services in
which data is sent from the Internet, is processed and converted by
the Service Node, and is used as the basis for data to be sent across
the PSTN. Each package of data is related to a specific request. The
logical entity consuming it within the Service Node is different from
that dealing with the associated request.
The pattern of interaction between the requesting Internet entity and
the one dealing with the request in the Service Node is, at least
initially, straightforward. The services described earlier can be
arranged with a simple invocation and response sequence. This differs
from the situation that occurs in "traditional" I.N. services, where
any extra service parameters are collected as the result of an
extended user interaction phase. With Internet-based requests,
however, it is quite possible to formulate a message with all of the
parameters required and then to send them all in one message. It is
possible that future services will require an extended dialogue, but
this is not needed at present.
The timing of the response (and its meaning) is significant. With
other Internet protocols (such as HTTP or Finger) the time taken to
perform the requested transaction and send back a response is short.
This means that the requesting entity can open a TCP connection to the
server, pass the request, hold the connection open, and expect the
response soon afterwards, after which the connection can be closed.
The requesting entity can set a time-out value so that, if a response
is not received in a certain time, the request is deemed to have
failed and the connection can be closed. However, when services are
delivered by a Service Node it can take a significant amount of time
before the requested transaction has become fully active. In
particular, the time until the PSTN part of the service has completed
L. Conroy, M. Lautenbacher, and R. Scholl [Page 10]
Service and Interface Analysis with Internet/I.N. Interworking
can be excessive. If the request is for a Web Activated Callback
Service, for example, the transaction may not be considered terminated
until after the call has completed; this could be (quite reasonably) a
considerable time.
In order to limit the time before an inoperative interface can be
detected, it is suggested that the protocol response should indicate
that the request has been received and accepted by the Service Node.
It is then the responsibility of that Service Node to carry out the
request. The way in which this is done is completely internal to the
Intelligent Network and so outside the scope of this work. This does
mean that a request may be accepted by the Service Node (as indicated
in the response sent back to the Internet) and then the service may
subsequently fail due to problems encountered in the PSTN. However,
the goal of restricting the "Initial Protocol" interactions to simple
request/response pairs makes this unavoidable.
It also means that all transactions are initiated by the Internet
device, without a separate event indication being initiated from the
Service Node. If such a Service-Node initiated transaction were to be
introduced it would add considerable complications, not only to the
protocols carried over the Internet but also in the internal operation
of the Service Node. As such it would require closer coordination
between the groups defining the operation of the Intelligent Network
components (ITU SG11 and the regional telecommunications standards
bodies) and the IETF. This would (at least) delay the introduction of
the services. As work develops in these external bodies, the Internet
protocols can be enhanced, but initially the gain is not worth the
wait.
The "transcoding" category of service requires data to be sent, as
well as the basic request message. The security requirement of the
information carried in these two protocols is different. As mentioned
in the section on Security Considerations, the request message may
well carry information that has charging significance; it may include
parameters that validate or authorise the request and so must be
protected. As someone may be charged for the provision of the service,
it is important that any PIN is kept secure. The data message that is
needed for one category of services has a lesser requirement. Whilst
it is unfortunate if the content of an email is intercepted, it should
not have a financial significance. Likewise, the content of the data
sent to the Service Node may be intercepted, but the consequences of
this are not as potentially severe.
In the category of service mentioned above (and initially described in
[1]) that requires a data message to be sent, the transaction is again
initiated from the Internet. The data is sent from the
Internet-connected device making the request, and is delivered to the
Service Node. As such, this transaction can be organised using a
straightforward TCP-based file transfer protocol. The connection is
opened by the requesting entity, the title and then the data is sent
and acknowledged, and then the connection is closed.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 11]
Service and Interface Analysis with Internet/I.N. Interworking
Where two messages are needed to carry the information needed to
process the service, these need to be coordinated. The request message
needs to be "tied in" with the data message. This can be done either
by a request parameter holding a reference that is used as the title
for the data transfer, or by the Service Node sending back a reference
number in its response to the request, with this being used as the
title for the data transfer.
The choice has an implication on the meaning of the rest of the
response. If the reference required by the data transfer is passed
back to the Internet device making the request in the response from
the Service Node, then any "success" parameter concerns the validity
of the request data, not that the overall request has been successful;
at this point the data transfer has not started.
As an alternative, if the Internet device generates its own reference
number and passes this TO the Service Node in its initial request then
the acknowledgement back from the Service Node to the Request can be
delayed until any data transfer has completed. This means that the
response can indicate the success or failure of the whole service
request. Unfortunately, there are problems with this scheme. There may
well be a number of Internet devices making requests of a Service Node
concurrently. There is a possibility that the reference numbers passed
in their requests are not unique, with the potential for ambiguity in
which data transfer relates to which request.
As such, it is suggested that the former scheme is used, whereby the
Service Node generates a unique reference number and sends it back to
the requesting device, with this value used as an identifier in any
related data transfer. In this case, acceptance of the overall service
request requires a positive acknowledgement both to the initial
request and to the separate data transfer (if any such transfer is
needed for the service requested).
The following diagram shows the two stage protocols sent between the
requesting Internet-based device and the Service Node.
Note that the second phase of the transaction is used only where the
service requires extra data to be sent. Note also that, although shown
as separate entities, the service node components may share the same
address and appear as one item to the requesting device. To enable
this, the entities responding to the service request and the optional
data transfer could register on different TCP ports.
Internet Device SN Request Handler SN Data Handler
|-service request ------------------->
.
<-- request ack (+optional ref.no)---|
|-- (optional) request data + ref.no ------------------>
.
<-- data ack ------------------------------------------|
L. Conroy, M. Lautenbacher, and R. Scholl [Page 12]
Service and Interface Analysis with Internet/I.N. Interworking
6. Security Considerations
It is of utmost importance that the operation of the PSTN must not be
damaged by operation of this interface. Two levels of protection are
needed to ensure this:
(i) the Interface is associated with a Service Node.
This choice means that interaction with rest of the PSTN is
restricted; there is NO connection to the SS7 Network from a Service
Node, and any Central Office to which the Service Node is connected
can use its "normal" access protection features to isolate it if it
starts to behave incorrectly.
The use of a Service Control Point (or SCP - a unit that implements
just the SCF and has a connection to the SS7 network) might be
considered. However, if an association were to be made between the
Internet and an SCP rather than a Service Node, then any subversion of
this unit would put the whole of the Telephone Network's signalling
system in jeopardy and (as it has access via the SS7 network to all
SSPs and so to all of the Central Offices) the whole of the Telephone
Network.
(ii) the Interface must allow access control and secured exchanges
between I.N. components and Internet connected devices. There are
several reasons for this, and these are indicated briefly here.
A large proportion of the information flowing across this interface
will have charging and billing significance; PSTN Network Providers'
customers being provided with services will be charged for them, so
any information authorising or authenticating users that is passed
over the Internet towards the interface must be protected against
interception.
Where service requests are accepted and transferred across this
interface from a restricted set of nodes, protection against source
spoofing, "man in the middle" and replay attacks must be considered.
The interface must be designed so that the impact on operation of the
Service Node, and, more generally, the PSTN, of denial of service
attacks can be minimised. Where possible, the interface should be
designed so that service can continue to be provided to some Internet
nodes in the face of such attacks from errant or malicious sources on
the Internet.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 13]
Service and Interface Analysis with Internet/I.N. Interworking
Integrity of charging information is important, and enough information
must be collected to assure non-repudiation of charges. This presents
a problem where the source of a request is on an untrusted network;
mutual authentication may well be required, and this implies that
there will be a definite lifecycle to the relationship between the
Service Node and the Internet Devices that generate the requests. This
lifecycle in turn may be the subject of attack in terms of state
synchronisation disruption. Where the Internet devices that send
requests to the Service Node are themselves acting as servers for
other Internet connected users (such as a Web Server providing a
Web-Activated Callback Service to browsers), there may also be a need
to ensure that authentication information passed from the "end user"
is available and can be passed on to the Service Node in a secure
manner.
7. References
[1] I. Faynberg, M. Krishnaswamy, and H. Lu.
INTERNET-DRAFT:draft-faynberg-telephone-sw-net-00.txt,
"A Proposal for Internet and Public Switched Telephone
Networks (PSTN) Internetworking". Issued March 1997
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah,
"The Intelligent Network Standards, their Application to
Services". McGraw-Hill, 1996
[3] J. Thorner, "Intelligent Networks". Artech, 1994
[4] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[5] T. Berners-Lee, R. Fielding & H. Frystyk, RFC 1945,
"Hypertext Transfer Protocol -- HTTP/1.0". May 1996
[6] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993
L. Conroy, M. Lautenbacher, and R. Scholl [Page 14]
Service and Interface Analysis with Internet/I.N. Interworking
8. Authors Addresses
Lawrence Conroy
E-mail: lwc@roke.co.uk
Telephone: +44-1794-833666
Fax: +44-1794-833434
Roke Manor Research Limited
IT&N-INIA Group
Roke Manor, Old Salisbury Lane,
Romsey, Hampshire SO51 0ZN
U.K.
Markus Lautenbacher
E-mail:markus.lautenbacher@oen.siemens.de
Telephone: +49-89-722-37805
Fax: +49-89-722-23528
Siemens OEN MD13
Machtlfinger Strasse 10
Munich D-81359
Germany
Reinhard Scholl
E-mail:reinhard.scholl@oen.siemens.de
Telephone: +49-89-722-22119
Fax: +49-89-722-62366
Siemens OEN MB21
Hofmannstrasse 51
Munich D-81359
Germany
L. Conroy, M. Lautenbacher, and R. Scholl [Page 15]
Service and Interface Analysis with Internet/I.N. Interworking
Appendix: PSTN-101
What is normally considered as "the Telephone Network" consists of a
set of interconnected networks. Potentially, each of these networks
could be owned by a different Network Operator. The official name for
such a network is Public Switched Telecommunications Network (PSTN). A
simple PSTN consists of a set of Switches (called Central Offices or
Telephone Exchanges) with links interconnecting them to make up the
network, along with a set of access connections by which terminals are
attached. The PSTN is used to deliver calls between terminals
connected to itself or to other PSTNs with which it is interconnected.
Calls on the PSTN are circuit switched; that is, a bi-directional
connection is made between the calling and called terminals for the
duration of the call. In PSTNs the connection is usually carried
through the network in digital format occupying a fixed bandwidth;
this is usually 56 or 64 Kbps. Messages are sent between the Switches
to make and dissolve connections through the network on demand and to
indicate the status of terminals involved in a call; these
"signalling" messages are carried over a separate (resilient) data
network dedicated to this purpose. This signalling network is also
known as the Common Channel Signalling (CCS) or Signalling System
Number 7 (or SS7) network after the names of the signalling protocol
suite used.
As yet, the majority of access connections to a PSTN carry analogue
signals, with simple (analogue) telephones as terminals. Call requests
are indicated to the Central Office to which a telephone is connected
either by a sequence of pulses or tone pairs being sent.
Notifications on the status of the request are sent back to the
telephone in the form of tones. Indication from a Central Office that
a call is being offered to a telephone is arranged by sending an
alternating voltage down the access connection which in turn causes
the ringer in the telephone to sound. These access lines have a unique
address associated with them and can support a single call.
However, with analogue or digital multi-line connections, or
Integrated Service Digital Network (ISDN) Basic or Primary Rate
Interfaces (BRI or PRI), several concurrent calls are possible and a
set of addresses are associated with them. The new ISDN access
connections are designed so that data exchanged with the network is in
multiplexed digital form, and there is an individual channel for each
of the potential connections, together with a separate channel
dedicated to sending and receiving call request and call alert data as
well as carrying packet switched user data. These call request and
call alert messages the equivalent of the pulses or tones that are
sent when dialling, and the ringing signal that is sent to a telephone
when a call is being made to it.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 16]
Service and Interface Analysis with Internet/I.N. Interworking
The operation of the call request is fairly simple in most cases. The
user presses a sequence of numbers on a telephone handset, and the
telephone passes a sequence of digits (either as pulses or tone pairs)
to the Central Office via the access line. The Central Office contains
a processor that will be notified that the user has made a request and
the digit string that is the sole parameter of the request. This digit
string is taken to be the unique address of an access line connected
either to itself or to another Central Office. There is a hierarchical
addressing scheme, so that the digit string can be parsed easily. A
call request to a terminal connected to a remote Central office can be
routed by examining the digit string passed; the Central Office will
extract the part of the passed address that corresponds to the remote
Central Office in question, and can route the request onward, forming
an inter-switch call request and passing it via the signalling
network. At the same time it will allocate one of its available
transmission channels towards the remote Central Office.
This scheme has been used since the 1950s, and suffices for the
majority of calls. However, there are a range of other services that
can (and have been) provided, enhancing this basic call processing.
Freephone or Premium Rate services (1-800 or 1-900 services)are good
examples of the supplementary services that have been introduced.
Apart from the important feature that the cost of these calls is
varied so that the caller does not pay for a freephone call, or pays
an extra charge for a premium rate call, they have the similarity that
the number dialled must be translated to arrive at the "real" address
of the destination terminal. They are known as number translation
services, and make up the bulk of all supplementary services delivered
today.
These were originally programmed into each Central Office, but the
complexity of maintaining the data tables on each processor grew
cumbersome, so a more general solution was sought. After a
considerable gestation period, the eventual solution was the
Intelligent Network. This takes the separation of Central Offices and
the network links interconnecting them a stage further.
The Central Offices are considered to provide the Call Control
Function (CCF). In addition, the Service Switching Function (SSF) is
provided to "enhance" the operation of these Switches by detecting
when a particular request has been made (such as by dialling 1-800).
If this pattern is detected, the equipment implementing the SSF will
send a specialised request message over the signalling network to a
separate computer that implements the Service Control Function (SCF).
This entity is responsible for querying service specific data (held in
a unit providing the Service Data Function, or SDF), performing any
digit translations necessary, and sending the details of how to
proceed back to the SSF, where they are obeyed and the call is put
through to the "real" destination.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 17]
Service and Interface Analysis with Internet/I.N. Interworking
The advantage is that there can be a much smaller number of physical
units dedicated to the SCF, and as they are connected to the
signalling network they can be contacted by, and can send instructions
back to, all of the units providing the SCF. In another enhancement, a
separate entity called the Special Resource Function (SRF) was
defined.
Equipment implementing this function includes announcement units to
play recorded messages (for example, prompts to enter digits) to
callers. It will also include the tone decoders needed to capture any
digits pressed by the caller in response to the prompts. Finally, it
will include a connection (directly or indirectly) back to the SCF.
This allows the digits pressed by a caller to be passed to the SCF on
demand.
For example, the SCF can ask an SSF handling a call to route the
caller temporarily through to an SRF. It can then instruct the SRF to
play an announcement and to collect a set of digits from the caller.
Once this has been achieved, the SCF can ask for the temporary
connection to be dissolved, can ask for a message giving the digit
string collected, and can use this as an extra parameter to the
service request.
This pattern of user interaction is commonly used where telephone
charge cards are used to make a call, in which case the extra account
information and PIN can be captured in this way, passed on to the SCF,
where it can be checked against the correct values stored in the
service database prior to allowing the call to proceed.
An overall diagram showing the functional entities involved in a
PSTN/I.N. combination is shown in Figure A. One possible configuration
for these entities is shown in Figure B. However, where Internet
connection is intended, the configuration is slightly different, as
shown in figure C.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 18]
Service and Interface Analysis with Internet/I.N. Interworking
FIGURE A:
[SCF] [SDF]
| |
____________-_________-_______________________
| | | |
o^o [ SSF ] | [ SSF ] o-o |
/\----------[CCF].........[CCF].......[CCF]------/\ |
-- \ -- |
\ |
-----------------------------------------[SRF]
key: ____ signalling relationship
---- access relationship
.... inter-switch relationship
FIGURE B:
[SCP] [SDP]
| |
____________-_________-_______________________
| | | |
o^o [ SSP ] | [ SSP ] o-o |
/\----------[CCP]..........[CO]......[CCP]-------/\ |
-- \ -- |
\ |
-----------------------------[Intelligent Peripheral]
key: ____ signalling (SS7) network
---- access line
.... inter-switch (trunk) lines
SSP = Service Switching Point - a unit that implements the Service
Switching Function
CCP = Call Control Point - a unit that performs call control functions.
This is normally a kind of Central Office (shown as CO above)
SCP = Service Control Point - a unit implementing the Service Control
Function. NOTE that this is connected to the SS7 Network and uses
this connection for all of its communications.
Intelligent Peripheral - this is a unit (also known as an IP) that
contains specialised resources (like announcement units, tone
decoders). In effect, it implements Special Resource Functions.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 19]
Service and Interface Analysis with Internet/I.N. Interworking
FIGURE C:
-----[Service Node] - - - - (Interface) - - [Internet Device]
\
\
\ _______________________
o^o \ | | | o-o
/\----------[CO].........[CO]......[CO]--------/\
-- --
Note: The Service Node is only connected to the Central Office as a
peripheral; it has NO connection to the SS7 network. It performs a
similar task to the SCP, SDP, SSP/CCP, and Intelligent Peripheral in
figure B.
L. Conroy, M. Lautenbacher, and R. Scholl [Page 20]