Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Wed, 9 Nov 2005 15:24:23 +0530

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-masked] [mailto:[email-masked]]On
Behalf Of Tolga Asveren
Sent: Wednesday, November 09, 2005 1:17 AM
To: [email-masked]
Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Tuesday, November 08, 2005 2:48 PM
> To: [email-masked]
> 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-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: Tuesday, November 08, 2005 7:19 PM
> To: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 Nov 2005 03:24:40 -0700

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.

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)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 08:00:25 -0500

Shashank,

> From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 4:54 AM
> To: [email-masked]
> Cc: 'Tolga Asveren'; [email-masked]'
[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.
> Ur view of IPSPs in Single Ended (SE) mode (picking up from some old
[TOLGA]the above is not my view on SE-IPSP.
> 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
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.

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 9 Nov 2005 08:09:49 -0500

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2005 5:25 AM
> To: Prasad, Shashank S (Shashank)
> Cc: [email-masked]; 'Tolga Asveren'
> Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Shashank,
>
[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.