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
than SGPF and ASPF and does not send/receive messages. I believe 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
>