NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
Chair(s):
Steve Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@lucent.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:spirits@lists.bell-lab.com
To Subscribe: spirits-request@lists.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:
Done |
|
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 |
Nov 00 |
|
Protocol Requirements Document submitted for publication as an Informational RFC |
Internet-Drafts:
Request For Comments:
RFC |
Status |
Title |
RFC2995 |
Pre-Spirits Implementations of PSTN-initiated Services |
49th IETF SPIRITS Working Group Meeting Notes
Reported by Alec Brusilovsky.
Recorded by Kumar Vemuri, to whom both co-chairs express their deepest appreciation for the excellent job.
SPIRITS WG met in the afternoon of Tuesday, December 12, 2000.
There were 106 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky
Agenda
1. Agenda bashing and goals of the session - 5 minutes;
2. SPIRITS progress in ITU-T - Hui-Lan Lu - 5 minutes;
3. Discussion on the additions to the SPIRITS Architecture Document - 5 minutes;
4. Discussion on the SPIRITS Protocol Requirements - 20 minutes - I. Faynberg;
5. Next step - SPIRITS Protocol - 20 minutes;
6. Wrap-up - 5 minutes.
1. Agenda bashing and goals of the session
A question on PINT related issues.
The chair requested this discussion to be taken to the PINT list.Agenda was accepted without changes.
2. SPIRITS progress in ITU-T - Hui-Lan Lu
ITU IN Architecture and Requirements WG requested the most recent SPIRITS information. RFC 2995, The Spirits Architecture document, IN and PINT related Requirements for Spirits Protocol were shared with the ITU-T. The IN group in the ITU took this information from the Spirits architecture and included this in one of their draft recommendations. The drafting session in Geneva resulted in a Spirits example configuration in Q.1244. More discussions may take place in the next ITU IN WG meeting.
3. Discussion on the additions to the SPIRITS Architecture Document
Alec B. talked about working on the protocol. There was consensus on the SPIRITS architecture at the last meeting, now we ought to start work on the protocol requirements. Alec asked for an open discussion of Spirits related architectural issues, based on items discussed on the Spirits mailing list.
Issue: Comments on architectural framework. There's one interface between the PINT server and the PINT gateway. This interface was not addressed in detail. Some people suggested that that interface be made Corba based. The Spirits proxy in the modified architectural view becomes a gateway like entity on the domain interface, and that this does not impact the architectural diagram.
Alec took the Hum for keeping existing architecture vs. redrawing architecture to reflect similarities or symmetries with PINT.
The Hum for the former approach was louder. So the WG will be going forward with the existing architecture. The Architecture Document will be submitted to the IESG as a candidate for the Informational RFC.
4. Discussion on the SPIRITS Protocol Requirements - I.Faynberg
Igor (de-facto Document Editor) talked about Spirits requirements. Igor summarized the changes to be made reflecting recent discussions. Igor suggested that the present document will be modified according to Sören's proposal to include the words that will specifically say that PINT implementation is not a requirement for a SPIRITS implementation. He also mentioned that there was much useful text in Lawrence's and Jim's drafts and asked that Sören, Jörgen, Lawrence, and Jim mail to him the pieces of their respective documents to be included in the requirements within the first couple weeks after the meeting. The speaker talked about using IN as a mechanism for transporting notifications. Some changes were made to the mention of CAMEL related issues in the document. Igor talked about DPs in the call model that would be "SPIRITS enabled", and about the need to pick the appropriate CS (CS-2 or CS-3?) for this as the base model. He then discussed the use of the SIP SUBSCRIBE and NOTIFY mechanisms for SPIRITS.
Issue: How one could use SUBSCRIBE and NOTIFY methods when a protocol was not already selected.
Answer: the method names as used are merely indicative of the capabilities supported, not that we are talking about protocol specifics at this time.
Regarding persistent interactions, setting dynamic triggers etc., one may have to also use PINT building blocks to support SPIRITS end-to-end call flows. There is a possible problem in recursion: Changes in PINT impact SPIRITS and vice versa. We need PINT-related requirements in SPIRITS and vice-versa.
Issue: It should be possible to implement SPIRITS without implementing PINT.
Answer: We're not saying it is absolutely necessary, but we will also not discourage the use of PINT. Some requirements will continue to address the issue of what happens in SPIRITS, when we use PINT.
Alec B.: During the previous SPIRITS WG meeting in Pittsburgh we agreed that it is not necessary to implement PINT in order to implement SPIRITS.
Issue: JAIN/PARLAY and 3GPP APIs should interact easily with SPIRITS. Maybe we should look to these APIs while building a requirement set for SPIRITS.
Chair: Since IETF does not have formal relationships with JAIN and PARLAY, this may not be possible in all cases.
Both chairs asked for a Consensus Hum: Should we move on this (Requirements) document - is it ready to progress? Yes (based on the Hum). The Requirements Document will be shortly posted for a WG Last Call on the mailing list.
5. Next step - SPIRITS Protocol
The Architecture and the Protocol Requirements work is pretty much done. We are coming closer and closer to the actual SPIRITS Protocol work. Chairs asked for the Protocol Proposals I-Ds to be submitted and for the volunteers for the Protocol Team to identify themselves.
Follow-up on PINT/IN-related SPIRITS Protocol Requirements
ITU-T Update