RE: M3UA: 1IPSP - multiple IPSPs traffic flow

Brian,
We indeed have a lot differences in our interpretation of IPSPs and the
modes.
I am seriously interested in the draft....so that we come to a common
underdstanding.


Few questions on ur last mail:

I had different idea about ASPF and SGPF in the IPSP block.
My original idea never had ASPF and SGPF in the same IPSP. 

However, I took the model at the face value from the old e-mail thread
discussions. From the e-mail thread discussions, I interpreted that IPSP
comprises 2 functionalities, ASPF and SGPF, independent of each other. There
can be a possibility that IPSP has ASPF + SGPF. Also, the IPSP can have ASPF
only or SGPF only ( I still have sink in this model :) )

But now I still read something different. From ur mail it seems that ASPF
uses the services of SGPF in its own IPSP to communicate to the peer...Did I
rightly interpret ur mail ?

If YES, then I have confusions and am not very sure if that should be the
intended model.

I understand that ASPFs in one IPSP should be talking to the SGPFs of the
peer and NOT the same IPSP. Hence I feel that ASP does NOT need the services
of SGPs, in the same IPSP.

How would u model, based on ur functionality...

         +------+          +------+
         |SCCP- |          |SCCP- |
         | User |          | User |
         +------+          +------+
         | SCCP |          | SCCP |
         +------+          +------+
         | M3UA |          | M3UA |
         +------+          +------+
         | SCTP |          | SCTP |
         +------+          +------+
         |  IP  |          |  IP  |
         +------+          +------+

Thanx.
shashank

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Wednesday, November 09, 2005 3:55 PM
To: Prasad, Shashank S (Shashank)
Cc: [email protected]; 'Tolga Asveren'
Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow


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

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