NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00
Chair(s):
Steve Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@lucent.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
Mailing Lists:
General Discussion:spirits@lists.research.bell-lab
To Subscribe: spirits-request@lists.research.bell-labs.com
In Body: subscribe or unsubscribe
Archive: http://www.bell-labs.com/mailing-lists/spirits/
Description of Working Group:
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group addresses how services supported by IP network entities can be started from IN (Intelligent Network) requests, as well as the protocol arrangements through which PSTN (Public Switched Telephone Network) can request actions to be carried out in the IP network in response to events (IN Triggers) occurring within the PSTN/IN. SPIRITS concerns architecture and protocols for secure transport of IN trigger information (requests for actions, as well as plain event notifications, including parameters) from PSTN/IN to the IP network, and optional responses from the IP network back to the PSTN/IN.
The SPIRITS architecture includes, but not limited to, three potentially independent entities:
- the SPIRITS client
- the SPIRITS server
- the PSTN/IN requesting system
The SPIRITS client is the entity that requests notification or some actions to be performed in the IP network. The SPIRITS server is the entity that receives notifications or requests from the PSTN/IN and returns optional responses back to the PSTN/IN, while initiating execution of the services requested in the IP domain. The SPIRITS server and PSTN/IN requesting sytem both reside in the IP domain, with PSTN/IN entity on the boundary between the IP and PSTN/IN networks. The presence of three independent parties implies a requirement to support complex trust models. Accordingly, the security architecture must support limited trust between the parties.
The parameters passed in any SPIRITS Service request are limited to information available from PSTN/IN entities. An example of such a service is Internet Call Waiting: on an incoming PSTN call, an IP node is notified of the call and can then carry out some actions. Definition of any information or data within the PSTN is the responsibility of the ITU-T and so is out of scope for SPIRITS.
The target of this working group is to describe building blocks for PSTN-IP services that start from PSTN/IN requests, and not to standardize the PSTN-IP services themselves. The WG will focus on an event-oriented design, rather than a service-oriented design. Specific services to be considered initially as examples are: (1) Incoming Call Notification (Internet Call Waiting); (2) Internet Caller-Id Delivery; and (3) Internet Call Forwarding and "Follow Me".
SPIRITS will:
o Produce an Informational RFC that describes current practices for supporting the services in question.
o Produce an Informational RFC on the overall architecture of SPIRITS-type services.
o Develop a Standards Track RFC that specifies a protocol by which PSTN Intelligent Network Service Nodes (or any other node that implements the Service Control Function) can request services of IP hosts, and which can return status indications to the PSTN/IN.
o Consider security and privacy issues relating to providing functions of SPIRITS type. In particular, understand any threats posed by this technology and address them in the proposed standard.
o Develop a standards track RFC for a SPIRITS MIB to support the service management protocol between Internet applications and the PSTN/IN Service Management System. The MIB is to conform to SNMP standards.
SPIRITS will collaborate with other IETF WG's working on similar issues and having expertise in PSTN/IP interworking (IPTEL, MMUSIC, PINT, SIP). SPIRITS will also establish communication with other relevant standard bodies (ITU-T SG11).
Goals and Milestones:
Apr 00 |
|
Current Practice document submitted for publication as Informational |
Jul 00 |
|
SPIRITS protocol submitted for publication as Proposed Standard |
Oct 00 |
|
SPIRITS MIB submitted for publication as Proposed Standard |
Internet-Drafts:
· On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center
· Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces
No Request For Comments
47th IETF SPIRITS Working Group Meeting Notes
Reported by Alec Brusilovsky.
Recorded by Goutam Shaw, to whom both co-chairs express their deepest appreciation for the job well done.
SPIRITS WG met on the afternoon of Monday, March 27, 2000.
There were 103 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky
Agenda:
1. Agenda bashing - 5 minutes.
2. Pre-SPIRITS implementations with focus on architecture
a. Telia/Nortel - 5 minutes.
b. Korea Telecom - 5 minutes.
c. NEC Corporation - 5 minutes.
d. Lucent - Igor Faynberg - 5 minutes.
3. Progress of Implementation Document - Hui-Lan Lu - 5 minutes.
4. SPIRITS progress in ITU-T - Hui-Lan Lu - 5 minutes.
5. EURESCOM P909 findings relative to SPIRITS WG objectives - Gianni Canal - 5 minutes.
6. What are SPIRITS architectural components? Do we know all of them? What other components SPIRITS needs? - Discussion on Architecture - 45 minutes. Lev Slutsman starts it off with a brief introduction.
7. SPIRITS Protocol requirements - protocol discussion - 25 minutes.
Alec Brusilovsky presented agenda and asked for suggestions or agenda comments.
1. Agenda Bashing
Agenda accepted.
2. Pre-SPIRITS implementations:
a. Nortel-Telia Service Gateway
(draft-nyckelgard-spirits-pre-impl-01.txt)
No questions or issues raised
b. Korea Telecom ICW
(draft-rhim-spirits-kticw-00.txt)
Issue: limited support for mobility, static calling number
c. NEC implementation of ICW
(draft-ago-spirits-icw-00.txt)
Issue: Q.1228 extensions used are: User-client identification process. Extended CS2 parameter.
d. Lucent Implementation of OCC
(draft-ietf-spirits-lucentocc-00.txt)
Issue: Firewall between the PSTN and the IP network is in reality there, but is not shown on the diagram.
Summary: three pre-SPIRITS implementations utilizing SIP and one - proprietary one, TCP/IP based.
3. Status of Informational RFC
All the internet drafts published.
Next is to compile the base material
- Introduction : compile the existing services
- Services - services description
- End of April for initial draft RFC commitment
Summary: all the internet drafts are published, next step is to compile the base material, first draft of the RFC to be published on the mailing list by the end of April.
4. ITU-T related issues: an update
- ITU-T recommendation Q.1231 lists PINT related IN services. Also Q.1241 describes Q.1241
- INAP extensions are slated for IN CS-4
- SG 13 has determined an IP framework and PINT architecture
- New drafted questions are IP telephony and PINT/SPIRITS related services
- Excerpts from SG11 docs. Can be brought into IETF
- Q.1224 is still a gray area as far as liasoning into IETF is concerned.
5. EURESCOM P909 findings relative to SPIRITS WG objectives
(draft-canal-p909-pint-spirits-00.txt)
- EURESCOM P909 overview
- P909 example services overview
- P909 architecture and requirements overview
Issue: PARLAY Gateway is in the diagram. It is there because API oriented approach was adopted P909 from the beginning. PARLEY represents just one example of implementation. The goal of this report and the I-D is to collect and offer services requirements to IETF SPIRITS (and PINT).
Issue: P909 architecture is available to the public and Gianni Canal will publish it on the SPIRITS mailing list.
6. SPIRITS Architectural components and protocol discussion
(draft-lslutsman-spirits-interfaces-00.txt)
Issue: SPIRITS protocol is between SPIRITS client and server. Remove CORBA from the diagram (it is not in the I-D)
Issue: SIP with possible extensions can be used as SPIRITS protocol. There is a need for the SPIRITS protocol requirements.
Issue: SPIRITS client cannot be classified as SCP. Remove SCP wording from the diagram.
Issue: C interface is for registration and notification
Issue: It is possible to introduce SPIRITS client as a gateway rather than an SCP ala Telia architecture.
Issue: Entities B and C both can be PINT protocol. A and B both should be doubled headed.
Issue: Do the Requirements Document To capture the business practices.
Issue: Two very important protocol requirements: interwork with INAP and PINT. Not everything in INAP is required, just enough to interwork with it.
Issue: Requirements RFC will be good starting point. Need to extend milestones part of SPIRITS Charter to include Protocol Requirements RFC. Volunteers for editorship were asked to talk to the WG chairs after the meeting. Igor Faynberg volunteered to write the detail on protocol requirements.
Issue: Include in the RFC suggestions what kind of messages need to flow between entities.
Summary: definite need for the Requirements Document, interworking with INAP and PINT are some of the requirements, chairs called for volunteers, Requirements RFC to be added to the SPIRITS WG milestones list.
Meeting adjourned
Toward Definition of the SPIRITS Architecture:SPIRITS Interfaces (5/2/00)
NEC Pre-SPIRITS ICW Implementation (5/2/00)
Outline of the Informational RFC on Pre-Spirits Implementations (5/2/00)
Outline of the Informational RFC on Pre-Spirits Implementations (6/7/00)
KT Internet Call Waiting Service
Toward Definition of the SPIRITS Architecture:SPIRITS Interfaces (6/7/00)
NEC Pre-SPIRITS ICW Implementation (6/7/00)
Lucent Technologies’ Online Communications Center Architecture
EURESCOM P909 contribution to PINT and SPIRITS
Telia/Nortel Pre-SPIRITS implementation (5/2/00)
Telia/Nortel Pre-SPIRITS implementation (6/7/00)