Subject: Re: Washington Agenda

From: "David Shrader" <[email-masked]>
Date: Thu, 04 Nov 1999 22:57:49 -0500

Alec,

I've been thinking of the "meta-protocol" concept and find some difficulty
with it. If we are really hoping to work with an IN, I think we have to
accept the fact that there are several "standards" of IN. We are primarily
familiar with the differences between AIN in the US and IN in the ITU and
that there are various customizations of this by ETSI and other groups. Add
to this, the real possibility that various other players may become involved
and want to use this framework: Parlay, JAIN, JTAPI, etc.

If I understand the "meta-protocol" concept, each of these "flavors" would
then be transported over this "meta-protocol" which would then require that
the server receiving the protocol interpret the specific flavor of IN that
is encapsulated. This, in actuality, limits the viability of the SPIRITS
work on an international (i.e., Internet) scale. (This also then sounds a
lot like the work in SIGTRAN.)

One of the valuable notions in PINT is that it is a specific protocol that
actually can work well with an ITU system, an AIN system, or some other
enterprise system, etc and there is no need to be concerned about national
or service provider variations.

Am I missing something about this concept?
David

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]

----------
>From: Alec Brusilovsky <[email-masked]>
>To: David Shrader <[email-masked]>
>Subject: Re: Washington Agenda
>Date: Thu, Oct 28, 1999, 12:18 PM
>

> David,
>
> One of the ways we can describe distributed system interoperability is a
> "metaprotocol" level, or a level under which all the other protocols fall and
are
> controlled.
> Metaprotocol that I have in mind will provide a framework and requirements for
an
> actual protocol without specifying one.
>
> SPIRITS charter says: "...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."
>
> This can be achieved by focusing on the protocol itself or starting from the
> metaprotocol framework. After defining metaprotocol we can:
> a) reuse any suitable existing protocol,
> b) extend a suitable existing protocol,
> c) come up with a new protocol.
>
> Regards,
> Alec
>
> David Shrader wrote:
>
>> Alec,
>>
>> Can you clarify what you mean by a "meta-protocol" vs. an "actual protocol"?
>>
>> David
>>
>> ----------------------------
>> David Shrader
>> Master Consultant, Inc.
>> [email-masked]
>>
>> ----------
>> >From: Alec Brusilovsky <[email-masked]>
>> >To: SPIRITS list <[email-masked]>
>> >Cc: David Shrader <[email-masked]>, Steve Bellovin
>> <[email-masked]>
>> >Subject: Re: Washington Agenda
>> >Date: Thu, Oct 28, 1999, 10:13 AM
>> >
>>
>> > Good morning,
>> >
>> > I would like to thank David for raising this very important and timely
issue.
>> > In fact, Steve Bellovin and I were discussing our proposed agenda for the
>> > upcoming November 9 (9 through 11:30 a.m.) meeting.
>> > Please see it below:
>> >
>> > 1. What is our output? Is it meta-protocol or an actual protocol? - 20 min.
>> >
>> > 2. Plan of work for the WG - 20 min.
>> >
>> > 3. Relations with ITU SG11 and SG13 - 20 min.
>> >
>> > 4. Interworking with PINT - 20 min.
>> >
>> > 5. Discussion on the published SPIRITS I-D - 20 min.
>> >
>> > Regards,
>> > Alec Brusilovsky
>> >
>> > David Shrader wrote:
>> >
>> >> Spirits Team Members:
>> >>
>> >> Do we have any kind of agenda for the December meeting? I took a look at
the
>> >> initial ID from Igor (and crew, thanks) and I think it is a good start for
>> >> describing the architecture and introducing the event reporting aspect of
>> >> the service. I think it is important for some discussion of the possible
>> >> responses from the Internet. That is, once the internet server has been
>> >> notified of an event, what can it instruct the PSTN/IN to do with the
call?
>> >> Typical responses could include: connect, holdcall, disconnect,
>> >> collectinformation, ... Can the server request the PSTN/IN to interact
with
>> >> the caller and wait for subsequent information from the PSTN/IN?
>> >>
>> >> I think it would be useful to discuss the scope of the response processing
>> >> at the meeting in Washington. I'd be willing to put something together.
>> >>
>> >> I think another area of discussion is the relationship to PINT. I think
>> >> there is some great potential for some neat services that actually combine
>> >> elements of both areas to provide the overall service.
>> >>
>> >> David
>> >>
>> >> ----------------------------------------------------
>> >> David Shrader
>> >> Master Consultant, Inc.
>> >> [email-masked]
>> >
>

---

From: [email-masked]
Date: Fri, 5 Nov 1999 09:55 -0000

David,

I think, Steve will agree with me. You are bringing an excellent discussion point for our Washington meeting on November 9. 
Indeed, we would like SPIRITS to work across multiple PSTN flavours. That is why we invite input from IN experts like Igor, Hui-Lan, Lev and yourself.

Regards,
Alec

----Original Message-----
   >From:     	David Shrader <[email-masked]>
   >To:         	[email-masked]
   >Cc:         	SPIRITS list <[email-masked]>
   >Date:    	Friday, November 05, 1999 05:01
   >
   >Alec,
   >

---

From: [email-masked] (Igor Faynberg)
Date: Fri, 5 Nov 1999 09:25:47 -0500

David Shrader wrote:

>familiar with the differences between AIN in the US and IN in the ITU 

[AIN is a subset of the ITU standard. There is a US IN Standard that should
emerge from ANSI soon. (A parenthetical comment.)]

>and that there are various customizations of this by ETSI and other groups. Add

[ETSI Core INAP is a subset of the ITU standard, too. (Another parenthetical 
comment.)]

>and want to use this framework: Parlay, JAIN, JTAPI, etc.

None of these is a protocol standard--they are all service creation
API. (Yet another parenthetical comment, but with the note--let us keep
apples and oranges apart. They may perfectly use the framework to produce
service creation environments, but the protocol should remain the same. [Unless,
SPIRITS goes with the Active Network approach :-) ]

>is encapsulated. 

If that were the case, I would scream, too. But my interpretation of the
"meta-protocol" concept, which I think corresponds to what Alec explained,
is exactly opposite. To communicate it in one word to David (who has
greatly contributed to the SS7 and ITU standards and knows the jargon), 
"meta-protocol" is something like Stage 2 (i.e., information flows+information 
elements) of the ITU-T methodology. This could be mapped to a "real"
protocol (e.g., SIP). For example, the IN protocol described at this level
in Distributed Functional Plane (Q.1214, Q.1224) is same for both the
US and ETSI variants. In other words, "meta-protocol" is the thing that
says what should be sent and when, but does not deal with the format.

I strongly agree with David that by no means should we produce more than one
protocol. This is precisely the reason we started with the DP information--
this IS common for all IN protocols, and--conversely--nothing else is.

>This, in actuality, limits the viability of the SPIRITS

Oh, not at all! SIGTRAN deals with the means of transporting SS7 and ISDN
access protocols. SPIRITS (and PINT) are defining the application protocol.

>or service provider variations.

Precisely!  Incidentally, what David said is a very good answer to the 
recurring question: "Why cannot we use INAP over TC over SIGTRAN." And I 
think we all plan to keep  PINT and SPIRITS this way. To this end, the
idea of "meta-protocol," as I understand it--chairmen, correct me if I am
wrong--is the first step toward doing that.  The next step would be
to chose the "real" protocol and map the "meta-protocol" to it.

>Am I missing something about this concept?

I believe David misinterpreted the concept. I strongly agree with every word
he said about the goal of SPIRITS though.

Igor