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

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

Brian,

Replies embedded.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, November 07, 2005 4:24 PM
To: Prasad, Shashank S (Shashank)
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow

Shashank,

The RFC is clear: the TM in the ASP Active Ack is the value that was sent
in the ASP Active.

In SE mode, the peer does not have a traffic mode.  It is acting like an
SGP.
Again, see A.2.2.

[SHASHANK] U are putting a lot of constraints by this statement. Ur
statement means that IPSP-IPSP cannot have a SE mode. This is NOT really
correct. Here I am trying to make some minor improvements in the M3UA specs
so that IPSPs can also use the SE effectively.

If you want both IPSPs to each have an AS an traffic mode, use DE instead
of SE.

[SHASHANK] This is a big contraint and not acceptable :)
IPSPs can surely use SE mode too between themselves (IPSPs). Moreover DE is
optional. 

--brian

Prasad, Shashank S (Shashank) wrote:               (Mon, 07 Nov 2005
15:06:34)
> Brian, 
> 
> ASPAC (and ASPAC-Ack) message has one Traffic mode and mutiple(n) Routing
> Contexts.
> My point is that the ASP Active message must have as many modes as Routing
> Contexts ....OR....
> 
> ...The implementation should club all the Routing Contexts with the same
> Traffic Mode in a ASP Active message and then send the others in a
different
> ASP Active.... This is possible but it is quite and indirect mechanism to
> send ASP Active messages....
> 
> 
> Verbatim from the specs:
> 
>    For the Application Servers that the ASP can be successfully
>    activated, the SGP or IPSP responds with one or more ASP Active Ack
>    messages, including the associated Routing Context(s) and reflecting
>    any Traffic Mode Type value present in the related ASP Active
>    message. 
> 
> 
> Does this mean that the Traffic mode in the ASPAC-Ack is the traffic mode
of
> the sender of ASP-Ack ?
> >From the RFC text "...reflecting any Traffic Mode Type value present in
the
> related ASP Active message ", I interpret that the Traffic Mode received
in
> the ASPAC messages shall be sent back in ASPAC-Ack.
> And it is NOT really the Traffic mode of the sender of ASPAC-Ack. 
> 
> And that's the issue which I see in the Single Ended mode wherein the
sender
> of ASPAC will never come to know the Traffic Mode of the peer. 
> 
> shashank
> 
> 
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, November 07, 2005 8:28 AM
> To: Prasad, Shashank S (Shashank)
> Cc: [email-masked]
> Subject: Re: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
> 
> 
> Shashank,
> 
> > > RFC 3332 says: (Section 4.3.4.3 second paragraph)
> > > 
> > >    For the Application Servers that the ASP can be successfully
> > >    activated, the SGP or IPSP responds with one or more ASP Active Ack
> > >    messages, including the associated Routing Context(s) and
reflecting
> > >    any Traffic Mode Type value present in the related ASP Active
> > >    message. The Routing Context parameter MUST be included in the ASP
> > >    Active Ack message(s) if the received ASP Active message contained
> > >    any Routing Contexts.  Depending on any Traffic Mode Type request
in
> > >    the ASP Active message, or local configuration data if there is no
> > >    request, the SGP moves the ASP to the correct ASP traffic state
> > >    within the associated Application Server(s).  Layer Management is
> > >    informed with an M-ASP_Active indication. If the SGP or IPSP
receives
> > >    any Data messages before an ASP Active message is received, the SGP
> > >    or IPSP MAY discard them.  By sending an ASP Active Ack message,
the
> > >    SGP or IPSP is now ready to receive and send traffic for the
related
> > >    Routing Context(s).  The ASP SHOULD NOT send Data or SSNM messages
> > >    for the related Routing Context(s) before receiving an ASP Active
Ack
> > >    message, or it will risk message loss.
> > > 
> > > I think that this is quite clear with regard to two things:
> > > 
> > > The IPSP receiving the ASP Active message responds with regard to
> Traffic
> > > Mode in the same fashion as an SGP would.
> 
> Prasad, Shashank S (Shashank) wrote:
> (Mon, 07 Nov 2005 05:17:59)
> > Brian,
> > I have only IPSPs in peer to peer communication.
> > There are no SGs. And therefore I would NOT consider SGPs or their
> > equivalent functionality.
> > 
> > Ur answer tends me to believe that the Single Exchange is ONLY between
an
> > ASP and SGP.
> > Which is NOT correct. Please refer to Sec 5.5.1 and Sec 5.5.2 in the RFC
> > 3332.
> > 
> > I can always have SE between 2 IPSPs. It is upto the IPSPs to exchange
the
> > right parameters in the messages to indicate to each other about
> > loadsharing.
> > 
> > 
> > shashank
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Nov 2005 05:46:55 -0700

Shashank,

I don't think that you understand SE mode.   Take a look back in the mail
archives for long discussions of the differences between SE and DE modes.
SE mode uses the same semantics as an ASP/SGP connection, where one IPSP
acts like an ASP in the exchange and the other acts like an SGP.

I find it strange that you refuse to use DE mode, yet seem to want to
mogrify SE into DE.

--brian

Prasad, Shashank S (Shashank) wrote:            (Mon, 07 Nov 2005 17:39:22)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 7 Nov 2005 07:54:58 -0500

Shashank,

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Prasad, Shashank S (Shashank)
> Sent: Monday, November 07, 2005 7:09 AM
> To: [email-masked]
> Cc: [email-masked]'
> Subject: RE: [Sigtran] M3UA: 1IPSP - multiple IPSPs traffic flow
>
>
> Brian,
>
> Replies embedded.
>
>
[TOLGA]I agree with Shashanks point here. IMO, we have an unnecessary
costraint in -SE-IPSP mode. I don't see any problem why using Traffic Mode
in both directions should create a problem. Forcing people to use DE-IPSP
mode -which is both optional and IMO more importantt han that not a really
peer-to-peer model- to set traffic modes in both directions is anot a
solution.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Nov 2005 06:21:47 -0700

Tolga,

The problem is that an SGP (intentionally) neither has an AS, nor does
it have a traffic mode.  This is the same for the SGPF in the SE model.
If you want to change the model, call it something different: how about
SG-SG? ;)

--brian

Tolga Asveren wrote:                       (Mon, 07 Nov 2005 07:54:58)

--X--snip--X--

> peer-to-peer model- to set traffic modes in both directions is anot a

--X--snip--X--

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 7 Nov 2005 09:01:40 -0500

Brian,

> Sent: Monday, November 07, 2005 8:22 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]I belive the main reason why we have different opinions about this
issue is because you think the logic in SE-IPSP as a SGPF whereas I would
call it IPSPF -OTOH I totally would agree with you that it makes sense to
speak of SGPF and ASPF in IPSP for DE-model-. It is true that the messages
exchanged to bring the entities up and ready for message exchange are the
same for SE-IPSP and SGP/ASP cases -mainly for the sake of reusing existing
message codes- but there is a fundamental difference between two models:
with SE-IPSP model, we have two different application logic processing
entities on each end, which may have different traffic mode attributes. It
sounds reasonable to me to have a mechanism to set both of those values with
Traffic Mode parameter.

For SG-SG, yes it could be nice indeed ;-)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Nov 2005 11:55:49 -0700

Tolga,

The SE model of RFC 3332 is SGPF/ASPF.

Look back at "M3UA-v02 Last Call Comment: ASP States and SE or DE IPSP".
You did not receive any support for your IPSPF model, even for rfc3332bis.

--brian

Tolga Asveren wrote:                           (Mon, 07 Nov 2005 09:01:40)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 7 Nov 2005 14:36:07 -0500

Brian,

> Behalf Of Brian F. G. Bidulock
> Sent: Monday, November 07, 2005 1:56 PM
> To: Tolga Asveren
> Cc: [email-masked]
[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?

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.

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 .

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Nov 2005 17:51:43 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 07 Nov 2005 14:36:07)

--X--snip--X--

> change -actually I would call it reverting back to the original model- or is

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.

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

--brian

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

> we have application logic at both sides, which may want to use different

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-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 8 Nov 2005 08:34:30 -0500

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

> Sent: Monday, November 07, 2005 7:52 PM
> To: Tolga Asveren
> Cc: [email-masked]
[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.
> (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.

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 8 Nov 2005 08:49:21 -0500

Brian,

[..snip..]
> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 8 Nov 2005 09:13:15 -0500

A few typo scorrected below.

> Behalf Of Tolga Asveren
> Sent: Tuesday, November 08, 2005 8:35 AM
> To: [email-masked]
> Subject: [Sigtran] SE-IPSP definition
>
>
> Brian,
>

^^^^^^^^^
                                                                  state
machine
> than SGPF and ASPF and does not send/receive messages. I believe
                                               ^^^^^^^^^
                                         certain messages, e.g. SSNM
> you use the