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


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 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)


         ********    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