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

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Mon, 7 Nov 2005 20:17:00 +0530

Thanx. Got it.

shashank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Tolga Asveren
Sent: Monday, November 07, 2005 7:37 PM
To: [email-masked]
Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

> -----Original Message-----
> From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> Sent: Monday, November 07, 2005 4:56 AM
> To: [email-masked]
> Cc: 'Tolga Asveren'
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Tolga,
> I picked up an old discussion thread that I had with u.
>
> What specifically did u mean, when u said - implementation dependent ?
> Did u mean local configuration ?
[TOLGA]Not really. In your example, it was the M3UA-user which was
performing loadsharing, i.e. deciding to use IPSP2 or IPSP3. So, loadsharing
will be done based on an implementation dependent mechanism in M3UA-User, it
has nothhing to do with M3UA itself.
>
> And what did u mean by Traffic Type ?
> Did u mean that IPSP1 can send ASPAC to the 2 IPSPs with Traffic Type as
> Loadshared ?
> If YES, then this would really not help because IPSP2 and IPSP3
> (illustrated
> below) are different entities by themselves.
[TOLGA]I was referring to type of traffic, e.g. SCCP class1, 800-number
lookup query etc.. The characteristics of traffic type would determine the
implementation dependent message routing mechanims in M3UA-User.
>
>
>
> shashank
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tolga Asveren
> Sent: Friday, November 04, 2005 8:51 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> This is implementation/traffic type dependent and is not something
> standardized by M3UA.
>
> > -----Original Message-----
> > From: Prasad, Shashank S (Shashank) [mailto:[email-masked]]
> > Sent: Friday, November 04, 2005 10:28 AM
> > To: 'Tolga Asveren'; [email-masked]
> > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Thanx Tolga. U are right in understanding my question.
> >
> > Followup Question:
> > Since IPSP2 and IPSP3 are serving the same AS, what would determine at
> > NodeB, if the traffic to IPSP1 is
> > to be sent via IPSP2 or IPSP3 ?
> >
> >
> > shashank
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Tolga Asveren
> > Sent: Friday, November 04, 2005 8:13 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> >
> >
> > Shashank,
> >
> > As far as I understand your question:
> >
> > You have IPSP1, IPSP2, IPSP3. You have one RK. IPSP sends ASPAC
> > for this RK
> > to IPSP2 and IPSP3. IPSP2 and IPSP3 are working in loadsharing
> > mode. You are
> > wondering whether IPSP1 will receive traffic from both IPSP2 and IPSP3.
> >
> > Yes, it can, but I wouldn't call it traffic being loadshared to
> > IPSP1. IPSP2
> > and IPSP3 are not the same entities. OTOH it makes sense to speak of
> > loadharing traffic from IPSP1 to IPSP2 and IPSP3 because traffic from a
> > single source is distrubuted to multiple peers.
> >
> >    Tolga
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Prasad, Shashank S (Shashank)
> > > Sent: Friday, November 04, 2005 9:48 AM
> > > To: [email-masked]'
> > > Subject: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > >
> > >
> > > Hi,
> > > I had a specific question related to a specific scenario
> explained below
> > > (Single Exchange scenario)
> > >
> > > NodeA supports 1 PS with 1 IPSP
> > > NodeB supports 1 PS with 2 IPSPs in Loadshared mode.
> > >
> > >
> > > There are two associations between NodeA and NodeB.
> > > The first association is between IPSP1 (NodeA) and IPSP2 (NodeB).
> > > The second association is between IPSP1 (NodeA) and IPSP3 (NodeB).
> > >
> > > The IPSP2 and IPSP3, which are serving loadshared for the PS2
> on NodeB,
> > > send an ASP Up to IPSP1 serving for PS1 on NodeA. Which means
> > > that IPSP2 and
> > > IPSP3,
> > > serving a loadshared PS2, are essentially telling NodeA to
> > > loadshare all the
> > > traffic
> > > for PS2, between IPSP2 and IPSP3.
> > >
> > > The above concepts are also illustrated below....(I have purposefully
> > > avoided AS-ACTIVE notification)
> > >
> > >
> > >
> > >          NodeA                   <------------NodeB------------>
> > >
> > >          PS1-IPSP1               PS2-IPSP2                 PS2-IPSP3
> > >           |                        |                          |
> > >           |<-----ASP Up------------|                          |
> > >           |-------ASP Up Ack------>| (Assoc #1)               |
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |<--------------------ASP Up------------------------|
> > (Assoc #2)
> > >           |----------------------------ASP Up Ack------------>|
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |<--ASP Active(Ldshr)----|                          |
> > >           |------ASP Active Ack--->|                          |
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |<--------------------ASP Active(Ldshr)-------------|
> > >           |----------------------------ASP Up Ack------------>|
> > >           |                        |                          |
> > >           |                        |                          |
> > >           |---NOTIFY(AS-ACTIVE)--->|                          |
> > >           |--------------------------NOTIFY(AS-ACTIVE)------->|
> > >           |                        |                          |
> > >
> > >
> > >
> > > Questions:
> > > Assuming a single exchange scenario, would the traffic towards
> > > PS1 on NodeA,
> > >
> > > be also loadshared across 2 associations ?
> > >
> > > I thought it would and hence another follow-up question:
> > > It looks like a loadshared peer (NodeB in our case) with
> > multiple IPSPs,
> > > is putting a constraint on the NodeA, to ALSO be ready to
> > receive data on
> > > multiple associations and possibly loadshared. Is this a fair
> > > understanding
> > > ?
> > >
> > >
> > > shashank
> > >
> > > _______________________________________________
> > > 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

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

---

From: "Prasad, Shashank S (Shashank)" <[email-masked]>
Date: Wed, 9 Nov 2005 17:39:47 +0530

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-masked]]
Sent: Wednesday, November 09, 2005 3:55 PM
To: Prasad, Shashank S (Shashank)
Cc: [email-masked]; '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
> 
> 
> Sent: Wednesday, November 09, 2005 1:17 AM
> To: [email-masked]
> > Sent: Tuesday, November 08, 2005 2:48 PM
> > To: [email-masked]
> > 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
> >
> >
> >
> > Sent: Tuesday, November 08, 2005 7:19 PM
> > To: [email-masked]
> > 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
> >
> >
> >

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