RE: M3UA: 1IPSP - multiple IPSPs traffic flow
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Brian, > -----Original Message----- > From: Brian F. G. Bidulock [mailto:[email protected]] > Sent: Wednesday, November 09, 2005 5:25 AM > To: Prasad, Shashank S (Shashank) > Cc: [email protected]; 'Tolga Asveren' > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > Shashank, > > For M3UA, ASPF is essentially an M3UA shim and an MTP-User. Two ASPF > can no longer communicate with each other than can two MTP-Users without > an underlying MTP provider (the SGPF). > > Tolga's view (if I'm right) is: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | IPSPF |----------------------|-| IPSPF | | > | |_______| | Association | |_______| | > |___________| |___________| > > However, this IPSPF is nowhere defined. [TOLGA]You are right that this is my view of IPSP, SE-IPSP to be more precise. OTOH I would disagree with you that this IPSP is nowhere defined. My interpretation of SE-IPSP as defined in the specification right now is the above architecture. It has a state machine and messaging rules defined for it. OTOH, neither the state machine nor the messaging rules are equivalent neither to ASP nor to SGP, e.g. IPSP can both send and receive ASPAC, does not use SSNM. As long as we agree *how* it works, naming it this way or that way is not really that important, as long as that naming issues don't slip into the specification. > > We had long discussions about this. When RFC 3332 was advanced we knew > that there were rather severe limitations with the IPSP models in RFC > 3332. We advanced the RFC anyway. The WG agreed that we would offer > IPSP as an extension draft. We largely decided that a new protocol > (perhaps using the same message set) was required for true peer-to-peer > communication. It looked like this: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | ASPF | | | | ASPF | | > | |_______| | | |_______| | > | | | | | | > | ___|___ | | ___|___ | > | | | | Association | | | | > | | SGPF |-|--------------------|-| SGPF | | > | |_______| | | |_______| | > |___________| |___________| > > Which is rougly equivalent to: > > IPSP A IPSP B > ___________ ___________ > | _______ | | _______ | > | | | | | | | | > | | IPSPF |----------------------|-| IPSPF | | > | |_______| | Association | |_______| | > |___________| |___________| > > IIRC we called it an SG-SG IPSP. It is even covered in the framework > document. Tolga wrote a draft. At some meeting it was supposed to > become a WG item. It died. > > rfc3332bis was advanced without repairing IPSP (but at least removing > some glaring errors from RFC 3332, yet introducing others). > > If one really wants to repair IPSP, it might be an idea to revive the > SG-SG draft and do IPSP properly. > > I can whip up a draft if anyone is truly interested. > > --brian > > Prasad, Shashank S (Shashank) wrote: (Wed, 09 Nov 2005 > 15:24:23) > > OK... > > On the technical terms defined by the standard, there is no difference > > between IPSPs and ASPs, except that it is used Point-2-Point > and do NOT use > > SGs in between. > > Of course, IPSP is NOT an SGP...that's for sure. > > > > Here the definition of IPSP verbatim from specs.... > > > > IP Server Process (IPSP) - A process instance of an IP-based > > application. An IPSP is essentially the same as an ASP, except that > > it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does > > not use the services of a Signalling Gateway node. > > > > > > > > > > ---- Picked from ur last mail ---- > > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > > application logic. OTOH the state machines and message semantics are not > > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor > would I say > > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, > just that -all > > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be > wrong to speak of > > DE-IPSP = ASPF + SGPF-. > > > > > > U said that the state machines and message semantics are NOT equivalent. > > Looking at the specs, I did NOT find any state machine > differences between > > ASPs and IPSPs too. > > > > I think the main contention that I have with u and Brian is that the > > definitions of IPSPs. > > U defined the modes based of the functionality of the IPSP. I > was delinking > > the modes from the definition of IPSPs. > > > > > > Ur view of IPSPs in Single Ended (SE) mode (picking up from some old > > threads) > > > > > > IPSP A IPSP B > > ___________ ___________ > > | | | | > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF | | | | ASPF | | > > | |_______| | | |_______| | > > | | | Association | | | > > | | __|____________________|__/ | > > | | / | | | > > | ___|_|_ | | _______ | > > | | | | | | | | > > | | SGPF | | | | SGPF | | > > | |_______| | | |_______| | > > | | | | > > |___________| |___________| > > > > > > And I think that we can also define IPSPs as follows and still > have the SE > > and DE configuration for both :) > > > > IPSP A IPSP B > > ___________ ___________ > > | | | | > > | _______ | | _______ | > > | | | | | | | | > > | | ASPF |----------------------|-| ASPF | | > > | |_______| | | |_______| | > > | | Association | | > > | | | | > > | | | | > > |___________| |___________| > > > > > > Any inputs on my interpretation of my IPSP definition from the RFC 3332 > > perspective ? > > > > > > Thanx. > > shashank > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On > > Behalf Of Tolga Asveren > > Sent: Wednesday, November 09, 2005 1:17 AM > > To: [email protected] > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > Shashank, > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On > > > Behalf Of Prasad, Shashank S (Shashank) > > > Sent: Tuesday, November 08, 2005 2:48 PM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Tolga, Brian, > > > I was going thru ur last mails and ur old discussions. > > > ( This mail is slightly long..excuse me for that ). > > > > > > I see new terms ASPF and SGPF. I haven't seen these terms in > the RFC 3332. > > > I guess, they mean ASP and SGP Function only and there is NOT really > > > something more than our understanding of ASP and SGPs. Am I right ? > > [TOLGA]We use the terms ASPF and SGPF to refer to the correspondign > > functionality in M3UA stack. > > > > > > > > > I also read all along (in this discussion and the thread > mails) that IPSP > > > can act as an SGP or an ASP. > > > This really confuses me. And may be I need additional clarification. > > > > > > > > > As stated in RFC 3332 the definition of IPSP is as follows: > > > > > > IP Server Process (IPSP) - A process instance of an IP-based > > > application. An IPSP is essentially the same as an ASP, > except that > > > it uses M3UA in a point-to-point fashion. Conceptually, > an IPSP does > > > not use the services of a Signalling Gateway node. > > > > > > Which clearly states that that IPSP is equivalent of ASP. I am > > [TOLGA]The similarity between ASP and IPSP is that both of them > are hosting > > application logic. OTOH the state machines and message semantics are not > > equivalent. So, I wouldn't say that IPSP is equal to ASP -nor > would I say > > that IPSP is equal to SGP, in my opinion an IPSP is an IPSP, > just that -all > > that assumes SE-IPSP-. For DE-IPSP, I think it wouldn't be > wrong to speak of > > DE-IPSP = ASPF + SGPF-. > > > NOT sure why > > > I would use IPSP for SGs. > > > SGP functionality should always be in SGs. Can I have SGPs > even on nodes > > > that are NOT Signaling Gateways ? > > > > > > > > > > > > Let's take the following simple example. > > > I have picked this example because the Rel 5 3GPP standards > use M3UA over > > > SCTP at its Core Network Signaling transport side (SCCP is > the ONLY M3UA > > > User). And as per the specs (29.202), it speaks about IPSP > considerations > > > for all the nodes (eg. RNC, SGSN...). It terms each M3UA node > (eg. RNC, > > > SGSN...) as "IP Node using M3UA User". > > > > > > There is a seperate Requirement for SGs in the 3GPP > standards. They follow > > > the SGP Requirements. > > > Essentially, both the peers will work in the pure IPSP-IPSP > mode (peer to > > > peer mode). > > > > > > I have never seen a mention of SE and DE as I feel that this > has been left > > > to implementation and various configurations that one might > want to choose > > > (Loadshared or Override) > > [TOLGA]I think the main reason for why you don't see much about > SE/DE mode > > in 3GPP documents is because SE/DE conmcept was not defined at > that time. > > Initially we had only SE-mode of operation. > > > > > > > > > ******** IP ******** > > > * IPSP * * IPSP * > > > ******** ******** > > > > > > +------+ +------+ > > > |SCCP- | |SCCP- | > > > | User | | User | > > > +------+ +------+ > > > | SCCP | | SCCP | > > > +------+ +------+ > > > | M3UA | | M3UA | > > > +------+ +------+ > > > | SCTP | | SCTP | > > > +------+ +------+ > > > | IP | | IP | > > > +------+ +------+ > > > |________________| > > > > > > > > > shashank > > > > > > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On > > > Behalf Of Tolga Asveren > > > Sent: Tuesday, November 08, 2005 7:19 PM > > > To: [email protected] > > > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow > > > > > > > > > Brian, > > > > > > [..snip..] > > > > > Regarding the issue we are discussing in this thread -being > > > > able to support > > > > > traffic mode in both directions-I think it is a nice thing to > > > > have, because > > > > > we have application logic at both sides, which may want to > > > use different > > > > > traffic . > > > > > > > > Again, the IPSP acting as an SGP in SE mode is not required to > > > > have a traffic > > > > mode. > > > > > > > > In the normal ASP/SGP exchange, the SGP does not have a traffic > > > > mode to place in > > > > the ASPAC Ack. Any traffic distribution towards the SGP is an > > > > SG-wide attribute > > > > and does not differ from AS to AS, nor ASP to ASP. > > > [TOLGA]I believe we have another one of those "rare" situations where > > > neither you nor I can convince the other one ;-) I think the > options and > > > supporting arguments are as follows: > > > > > > a)We don't need traffic mode bothways for SE-IPSP, because > one of SE-IPSPs > > > is mimicing a SGP and SGPs do not have traffic mode. > > > > > > b)We need traffic mode bothways, because both sides have > > > application logic, > > > which can have different trafic mode characteristics. (Shashank's > > > position) > > > > > > I subscribe to b) and as far as I understand you support a). > I think we > > > need to hear more from other people about this issue so that we > > > can reach a > > > conclusion. > > > > > > > > > Thanks, > > > Tolga > > > > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > > > Sigtran mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/sigtran > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ >