RE: SE-IPSP definition

Tolga,

My issues:

I am NOT able to understand the following IPSP model that Brian had said :)
I felt that an IPSP can have ASPF and SGPF but an ASPF using the services of
SGPF was NOT very clear.

            IPSP A                           IPSP B     
          ___________                      ___________  
         |  _______  |                    |  _______  | 
         | |       | |                    | |       | | 
         | | ASPF  | |                    | | ASPF  | | 
         | |_______| |                    | |_______| | 
         |     |     |                    |     |     | 
         |  ___|___  |                    |  ___|___  | 
         | |       | |    Association     | |       | | 
         | | SGPF  |-|--------------------|-| SGPF  | | 
         | |_______| |                    | |_______| | 
         |___________|                    |___________| 


Next is that u said that IPSP do NOT use SSNM messages.
I did NOT read anywhere explicit in the specs. Even the 3GPP standards want
IPSPs to receive and send DUPU and SCON :).


About the Traffic Mode both ways in SE:
We should surely add that enhancement suggested. My proposal was NOT based
on a different premise. I never had an ASPF using the services of SGPF. May
be the spec should draw these diagrams...


I had asked a question before:
How would ur model fit in assuming that I have two peers sending SCCP
messages to each other over an association ?

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


BTW, what is C/SE-IPSP and D/SE-IPSP


shashank



-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Tolga Asveren
Sent: Wednesday, November 09, 2005 8:26 PM
To: [email protected]
Subject: RE: [Sigtran] SE-IPSP definition


Shashank,

I don't think there is as significant issue as you mention. As far as I can
see, some text cleanup is the only thing we need-to get rid of C/SE-IPSP ,
S/SE-IPSP distinction-.

The original problem you mentioned -having traffic mode bothways- is
something useful IMO as well. That can be added to the document but it does
not change anything architecturally in terms of IPSP as defined in the
document.

What other issues do you consider as problems associated with IPSP?

   Tolga

> -----Original Message-----
> From: Prasad, Shashank S (Shashank) [mailto:[email protected]]
> Sent: Wednesday, November 09, 2005 10:08 AM
> To: 'Ken A Morneault (kmorneau)'; Tolga Asveren; [email protected]
> Subject: RE: [Sigtran] SE-IPSP definition
>
>
> Ken,
> There is a serious issue in understanding the differences in IPSP and what
> it means.
> I am sure that u would have gone thru the mails where serious
> issues of IPSP
> understanding is evident.
>
> I feel that it should be resolved in the next draft before anything else.
> An extention draft must include IPSP considerations.
>
> shashank
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ken A Morneault (kmorneau)
> Sent: Wednesday, November 09, 2005 8:12 PM
> To: Tolga Asveren; [email protected]
> Subject: RE: [Sigtran] SE-IPSP definition
>
>
>
>
> Hi Tolga,
>
> Sorry for the delayed response.  I took some time off.
>
> Regarding the IPSP text, that is an area that Javier
> updated.  At this point, I'm not sure if we will be
> able to change the text.  The document is supposed to
> be heading to the Editor's queue to be published.
>
> Regards,
>
> Ken
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Tolga Asveren
> Sent: Tuesday, November 08, 2005 9:13 AM
> To: [email protected]
> Subject: RE: [Sigtran] SE-IPSP definition
>
> A few typo scorrected below.
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Tolga Asveren
> > Sent: Tuesday, November 08, 2005 8:35 AM
> > To: [email protected]
> > Subject: [Sigtran] SE-IPSP definition
> >
> >
> > Brian,
> >
> > -changed the subject of the thread-
> >
> > Ken, I re-checked and current bis document seems to be updated
> > partially
> > (4.3 has the definition I copy/pasted below -which is fine-, OTOH
> > still there is text mentioning about C-IPSP, D-IPSP for SE-model. The
> > idea probably was to assign roles to IPSPS per "transaction", i.e. a
> > message pair like ASPAC/ASPAC-ACK, ASPIA/ASPIA-ACK, but I believe the
> > concept of "client"
> > and "server" can be misleading because it can be considered as one
> > IPSP always playing client or server role while communicating with a
> > certain peer IPSP. IMHO, the terms C-IPSP/D-IPSP confuse rather than
> > clarify.
> >
> > Brian, more comments below.
> >
> >    Tolga
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]On
> > > Behalf Of Brian F. G. Bidulock
> > > Sent: Monday, November 07, 2005 7:52 PM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> > >
> > >
> > > Tolga,
> > >
> > > Tolga Asveren wrote:
> > >                    (Mon, 07 Nov 2005 14:36:07)
> > >
> > > --X--snip--X--
> > >
> > > > [TOLGA]If you look to " M3UAbis - consensus on comment
> > resolution - Part
> > > > 1&2" thread -which has happened later than the thread you
> > > mentioned ;-) -,
> > > > you will see that everybody involved in the discussion
> > > "Valerie, you, myself
> > > > and Javier" agreed to return to the original SE-IPSP model. The
> > > conclusion
> > > > was to use the text proposed by Valerie. It seems the bis
> > > document is not
> > > > updated accordingly. Ken, was there a technical objection for that
>
> > > > change -actually I would call it reverting back to the original
> > > model- or is
> > > > this just an oversight?
> > >
> > > Really?  Did you mean in "M3UAbis - consensus on comment resolution"
>
> > > 23 Aug 2004 where Valerie says:
> > >
> > >  IPSP-SE behaviour:
> > >  The IPSP acting as the SGP must sends ASPAC-ack only when its side
> > > of the RK is  ready.  The IPSP acting as the ASP is responsible to
> > > retry the ASPAC until the  remote peer is ready.
> > >  When the IPSP acting as the SGP wants to stop application traffic
> > > from its side,  it must send ASPIA-ack.
> > [TOLGA] No, what I mean is  the message on 08/30/2004 "M3UAbis -
> > consensus on comment resoluti on-Part 1&2"
> >
> > 1- IPSP Single Exchange (SE) model. Only a single exchange of ASPTM
> >       or ASPSM messages is needed to change the IPSP state. This means
> >       that a set of request from one end and acknowledge from the
> other
> >       will be enough. The RK must define both sides of the traffic
> flow.
> >       Each exchange of ASPTM or ASPSM messages can be initiated by
> either
> >       IPSP. For this exchange, the initiating IPSP follows the
> procedures
> >       described in section 4.3.1.
> >
> > The above is the original concept we defined for SE-IPSP mode.
> > There are no
> > predefined client/server relationship, a pure peer-to-peer
> relationship.
> > >
> > > Or did you mean where we agreed to back out of the v03 changes
> > > (which is what I think you are referring to with the IPSPF) and go
> > > back to the
> > > v02 description
> > > (which is the same as RFC 3332 and the SGPF/ASPF approach).
> > [TOLGA]No, what I mean as "IPSPF approach is v02 definition. As long
> > as the problem is how you and I name it, there is no problem from
> > specification point of view but I would call it IPSPF because it has a
>
> > different machine
>
> ^^^^^^^^^
>                                                                   state
> machine
> > than SGPF and ASPF and does not send/receive messages. I believe
>                                                ^^^^^^^^^
>                                          certain messages, e.g. SSNM
> > you use the
> > term SGPF in the context of a "transaction" not inthe context of the
> > overall realtionship between two peer IPSPs.
> > >
> > > --brian
> > >
> > > >
> > > > Considering the way it is supposed to work, i.e. according to
> > > the text we
> > > > had concensus on, we can't speak of exact SGPF semantics for
> > > SE-IPSP even
> > > > from basic message exchange point of view, e.g. SGPF does not
> > > send ASPAC,
> > > > can't receive ASPAC-ACK, sends SSNM etc...With SE-IPSP both
> > > sides can send
> > > > ASPAC/ASPAC-ACK and they don't send SSNM and they have a
> > > > peer-to-peer relationship, not a client/server relationship.
> > >
> > > See Valerie's description above.  As I have mantained, it is clear
> > > that one IPSP acts in an SGP role and the other in an ASP role.
> > >
> > > >
> > > > 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.
> > >
> > > --brian
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email protected]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>



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