RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

> -----Original Message-----
> From: Prasad, Shashank S (Shashank) [mailto:[email protected]]
> Sent: Wednesday, November 09, 2005 4:54 AM
> To: [email protected]
> Cc: 'Tolga Asveren'; '[email protected]'
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> 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.
[TOLGA]Did you consider the state transitions inside brackets, which are
only valid for IPSP case for AS state machine per ASP (Figure3 in the
specification)? An ASP can't receive ASPAC an IPSP can etc... Furthermore
ASP can receive and generate SSNM, an IPSP doesn't. ASP and IPSP are
different things from M3UA message processing point of view. OTOH they are
similar because both of them host application logic.
>
> 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  | |
>        | |_______| |                    | |_______| |
>        |           |                    |           |
>        |___________|                    |___________|
>
[TOLGA]the above is not my view on SE-IPSP.
>
> And I think that we can also define IPSPs as follows and still have the SE
> and DE configuration for both  :)
[TOLGA]The point is whether something is really necessary or not., hence my
objection to DE-IPSP.
>
>           IPSP A                           IPSP B
>         ___________                      ___________
>        |           |                    |           |
>        |  _______  |                    |  _______  |
>        | |       | |                    | |       | |
>        | | ASPF  |----------------------|-| ASPF  | |
>        | |_______| |                    | |_______| |
>        |           |    Association     |           |
>        |           |                    |           |
>        |           |                    |           |
>        |___________|                    |___________|
>
>
> Any inputs on my interpretation of my IPSP definition from the RFC 3332
> perspective ?
The way SE-IPSP currently defined is:

 +-------------+           +-------------+
 |  IPSP A     |           |   IPSP B    |
 |             |           |             |
 |             |           |             |
 | +-------+   |           |  +-------+  |
 | |       |   |           |  |       |  |
 | | IPSPF +---+-----------+--+IPSPF  |  |
 | |       |   |           |  |       |  |
 | +-------+   |           |  +-------+  |
 |             |           |             |
 |             |           |             |
 +-------------+           +-------------+

We don't need to change something architecturally about it, just the
document needs a bit of cleanup.
>
>
> 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
>