Subject: Draft on Spirits Architecture

From: "Raymond Forbes" <[email-masked]>
Date: Mon, 14 Feb 2000 15:48:53 +0000

Observations on the Draft Architecture.

The list of architectures in chapter 3 do not translate into the figure.

in point 1 on the physical architectures it states that the SPIRITS Client may
be co-located with:
a. the IN SSP (not shown in the figure).
b. the IN SN (shown as interface A in the diaigram) functionally this is
implicit as the SN is defined as a combined SSP, SCP and IN IP.
c. the IN SCP (shown as interface E in the diagram).

This raises the question since the SCP and SSP have differing Call Models of the
Call State views is the planned interface for item b. above more like a. or c.
above? We need to split the porotocol with the related requirements from the
Physical representation. If the SPIRITS client needs to konw about services and
requests OR DPs, events and call states. If the SPRITS Client is in the SCP is
it using the SCF functionality (SLEE, SLPs, etc) or simply acting on the INAP
interface to the SSF as a Proxy server.

Items 2 through to 6 are not yet referenced in the functional models.

In IN, the SSP ( the physical representation of the IN switch client) is always
co-located with a CCF (ISDN switch or central office if you speak US) not shown
in the I-D.

I therefore assume that my point a. above should say the SPIRITS client may be
co-located with the IN SSF/CCF. Therefore the SSP incorporates the Switch or
Central Office.

Points 4 and 5 in the I-D Chapter 3 are confusing as the SPRITS client needs to
act on the Call/Service Specific Functionality in the MGC or Gatekeeper not the
Beare co-ordination functionality, Hence point 4 may decompose into point 5 as a
terminology/functional placement issue. The H.323 gatekeeper may also interact
via an IN SCP.  Point 4 appears to confuse functions with implementation, some
of the Call/Service Specific Functionality may be implemented as SLPs in the SCF
this is effectivly hosting part of the Gatekeeper on the SCP and part on the MGC
platform.

Ray Forbes
---------------------- Forwarded by Raymond Forbes/MAIN/MC1 on 14/02/2000 14:42
---------------------------

"David Shrader" <[email-masked]> on 14/02/2000 03:47:25

 To:      "SPIRITSList"                                       
          <[email-masked]>              
                                                              
 cc:      [email-masked](bcc: Raymond           
          Forbes/MAIN/MC1)                                    

 Subject: Draft on Spirits Architecture                       

In Lev's email regarding the spirits architecture work, he referred to an
outline of mine. I realized that I didn't send it to the list yet. I've
attached an initial draft for the architecture document. This document has
been submitted as an I-D. Rather than having everyone submit full drafts as
proposed by Lev, I propose that we start with my document and have people
submit items to insert into it and to provide comments on it. This approach
will reduce overlapping work for individual submissions and hopefully allow
us to produce a better draft prior to Adelaide.

The document is also available at
http://EyeForTheFuture.com/internet-drafts.

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

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 14 Feb 2000 11:22:26 -0500

Two things:

1) I completely agree with Ray's comments 

2) There is NO 'Draft Architecture' I-D on the SPIRITS page, nor has one been
yet submitted to the IETF. Therefore, what is being discussed is not a WG draft
but an e-mail message. (A small clarification.)

Igor

Raymond Forbes wrote:
>   --------------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML
> 
>                                            Name: draft-shrader-spirits-arch-00.txt
>    draft-shrader-spirits-arch-00.txt       Type: Plain Text (text/plain)
>                                        Encoding: base64
>                                     Description: Text - character set unknown