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/