Re: SE-IPSP definition

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
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 protected] [mailto:[email protected]]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Wednesday, November 09, 2005 2:08 PM
> > To: Tolga Asveren
> > Cc: [email protected]
> > 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.