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

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