Subject: Re: [Sigtran] SE-IPSP definition

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 18:18:55 -0700

Tolga,

I think that you are talking about something completely different
than RFC 3332.

Might I suggest a new IPSP draft that has things the way that you
want them?

--brian

Tolga Asveren wrote:                           (Wed, 09 Nov 2005 14:29:04)
> Brian,
> 
> 
> -I will try to consolidate my replies as much as I can-
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Wednesday, November 09, 2005 2:08 PM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Subject: Re: [Sigtran] SE-IPSP definition
> >
> >
> > Tolga,
> >
> > I an not talking about SNMM used to indicate the status of remote point
> > codes, etc.  I am talking about SNMM used to indciate the status of local
> > point codes, etc. for the sending IPSP.
> [TOLGA]ASPTM should be enough for that purpose. If one wants to be notified
> about remote user part status for IPSP case, one should have RKs defined in
> User Part granularity. For availability/unavailability there is ASPAC/ASPIA.
> We only miss the congestion message in ASPTM, which hopefully should be
> ready soon.
> >
> > Also, it might not be necessary (in all cases), it might not even be very
> > useful (in some cases), but it is currently not prohibited.
> a)I am not speaking of SG-SG at all, what I am saying has nothing to do with
> it. You also know that actually it is SG-SG, which is SSNM based -and which
> makes sense considering the services it needs to provide-, but this is not
> hte topic right now.
> 
> b)Your answer in  "M3UA User Part's Management" thread was about IPSP
> communication, if you want, you can check the original question in that
> thread. ;-)
> 
> c)The section you mention in "4.6 MTP3 Restart" is really really wrong and
> needs an update IMHO. An IPSP does not have MTP3 layer. One obviously can
> build a box which provides both SGP and IPSP services but IPSP functionality
> itself has nothing to do with MTP3. IPSP will host only local application
> logic which communicates directly with another application hosted byt a peer
> IPSP. Remote endpoint in traditional SS7 domain will be responsibility of
> SGP and MTP3 restart is applicable only for SGP, not for IPSP.
> 
> For the sake of making progress here is what I think:
> a)People are confused about use of SSNM for IPSP (I think we agree about
> this)
> b)SSNM is not necessary for IPSP case -except for SCON, which needs further
> study, i.e. ASPCONG-. If there is a situation where we *really* need it,
> let's try to figure out whether it can be handled with ASPTM. (This is my
> position. AFAICS, you also think that it is probably not a good idea to use
> SSNM either but you think that the document does not disallow this.)
> 
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran