RE: 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
>