Subject: RE: [Sigtran] SE-IPSP definition

From: "Holland, Peter Michael (Peter)" <[email-masked]>
Date: Thu, 10 Nov 2005 10:39:28 -0000

Brian,
Can I remind you that the definition of IPSP is:
   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.

Thus your mention of IPSP acting as an SGP is not according to spec.
Considering that definition, your statement:
> In SE mode,
> it was never intended that both sides behave like an ASP at the same
> time.  That is DE mode.
is not reflected in the spec - thus the confusion.

Pete

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 10 November 2005 10:23
> To: Holland, Peter Michael (Peter)
> Cc: 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] SE-IPSP definition
> 
> 
> Peter,
> 
> Holland, Peter Michael (Peter) wrote:            (Thu, 10 Nov 
> 2005 09:50:12)
> 
> --X--snip--X--
> > 
> > So you agree that it does not work so well when both ASs 
> have a redundant 
> > architecture - loadshare or override?
> > I don't understand why you refer to this as a pedantic 
> requirement - it is
> > an architectural/implementation robustness requirement in 
> some situations.
> > 
> --X--snip--X--
> 
> It is pedantic because an IPSP does not need an ASP Traffic Mode to be
> redundant.  When acting like an SGP, the peer IPSP can distribute
> traffic in accordance with the way that an ASP distributes messages to
> the SGP that make up an SG.  The SE-IPSP acting in SGP mode does not
> require an "ASP Traffic Mode".
> 
> Traffic Mode (the parameter) is an ASP concept.  Is is only 
> useful to an
> SE-IPSP in so much as the SE-IPSP is behaving like an ASP.  
> In SE mode,
> it was never intended that both sides behave like an ASP at the same
> time.  That is DE mode.
> 
> --brian
> 
> -- 
> 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: Thu, 10 Nov 2005 05:37:09 -0700

Peter,

A couple of comments:

- (See "[SUA issue 17 & M3UA issue #11] IPSP cases" in the archives, as
  well as "M3UA/SUA IPSP" and "IPSP proposed text (1st approach)"
  "IPSP-IPSP summary" "Consensus call (was: IPSP-IPSP summary)" "IPSP
  test (2nd approach)" "IPSP text - poll" "IPSP text (take 3?)" "Summary
  (hopefully) was: IPSP Text (take 3?)")

  There were several thousand mails exchanged on the topic.

- What you quote is just a definition, not a requirement.  (And in fact
  it is an old one that predates the SE model and the entire IPSP
  discussion.)  As it contains no requirements, there was no need to
  change it.

- The phrase "SGP or IPSP" occurs many times in RFC 3332 and RFC 3868.

- I invented SE mode (when the rest of the WG was demanding DE mode).
  If I had not argued through several hundred emails, you would only
  have DE mode now.

- To have a single exchange of messages it is a necessary that one side
  behave like an ASP (messages and state machines) and the other behave
  like an SGP (messages and state machines).

- An IPSP is often described as behaving like an SGP.

- John Loughney described how an IPSP responds to a received message in
  an attempt to limit complexity.  Because ASPs normally initiate
  messages, the passages describing IPSP decribe the IPSP as responding
  to the message in the same manner as an SGP (making the same state
  transitions and performing the same actions).  So even if an IPSP is
  defined as something like an ASP, its behaviour is most often
  described in the RFC as something like an SGP.

- Contrary to what Tolga says now, exchange of SSNM was always part of
  SE-IPSP.  It was exchange of ASPTM/SM that was questioned as whether
  it should be included in SE-IPSP communication at all.

- To limit changes to the RFC and move forward, we underspecified IPSP
  to allow for a wide range of combinations.  The resulting nightmare
  for interoperability was supposed to be addressed in extension drafts
  but never was.

- We purposely did not preclude any arrangements or interpretations in
  the RFC.  What functions the IPSP provides locally are closer to an
  implementation decision than a a protocol requirement.

- We intentionally did not introduce any changes to the ASP/SGP exchange
  for IPSP (we did not want define two protocols in one RFC).  Any
  changes to (or narrowing of) the normal ASP/SGP exchanges were to be
  addressed by extension drafts (but never were).

--brian

Holland, Peter Michael (Peter) wrote:           (Thu, 10 Nov 2005 10:39:28)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 10 Nov 2005 08:22:32 -0500

Brian,

[..snip..]
>   like an SGP (messages and state machines).
[TOLGA]Wrong. Take a look to Figure 3. IPSP can send and receive ASPAC/ASPIA
messages. As an example -just showing ASPAC messages-

 SE-IPSP1                    SE-IPSP2
     |                          |
     |-------ASPAC------------->|
     |                          |
     |<-----ASPAC-ACK-----------|
     |                          |
     |    AS is active at both  |
     |        sides             |
     |                          |
     |<-------ASPIA-------------|
     |                          |
     |------ASPIA-ACK---------->|
     |                          |
     |    AS is inactive        |
     |    at both sides         |
     |                          |

The above is a valid message sequence. Neither ASP nor SGP can support the
above message exchange. Thinking that an SE-IPSP behaves as ASP and the
other one as SGP for the whole set of message exchanges is wrong. I singled
out this issue because this is the key of the confusion. Basically, an IPSP
is an IPSPS neither ASP not a SGP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Nov 2005 06:55:12 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 08:22:32)
> is an IPSPS neither ASP not a SGP.

This message exchange is not required to be supported.

The following two other possibilities are just as valid:

   SE-IPSP1                    SE-IPSP2
       |                          |
       |-------ASPAC------------->|
       |                          |
       |<-----ASPAC-ACK-----------|
       |                          |
       |    AS is active at both  |
       |        sides             |
       |                          |
       |<-------ASPIA-------------|
       |                          |
       |-ERR[Unexpected Message]->|
       |                          |

   SE-IPSP1                    SE-IPSP2
       |                          |
       |-------ASPAC------------->|
       |                          |
       |<-----ASPAC-ACK-----------|
       |                          |
       |    AS is active at both  |
       |        sides             |
       |                          |
       |<-------ASPIA-ACK---------|
       |                          |
       |-------ASPAC------------->|
       |                          |
       |<---ERR[Mgmt. Blocking]---|
       |                          |

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 10 Nov 2005 08:46:34 -0500

Brian,

(To prevent mailing list pollution my last message on this subtopic -maybe
not on this thread- )

> Sent: Thursday, November 10, 2005 8:55 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Sorry but you are totally wrong. This is very well supported by
SE-IPSP state machine.
>        |-ERR[Unexpected Message]->|
[TOLGA] This is supported from M3UA point of view but means that your
SE-IPSP1 is either not an SE-IPSP or a broken one, because it does not
support IPSP state machine as defined by the specifications.
>        |<---ERR[Mgmt. Blocking]---|
[TOLGA]Hmmm, I am not sure about this. IMO no need to support this -because
SE-IPSP2 can send ASPIA instead of ASPIA-ACK- but OTOH this has nothing to
do with our discussion.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Nov 2005 07:34:14 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 08:46:34)
> [TOLGA]Sorry but you are totally wrong. This is very well supported by

It is not required by it.

Although we permitted either SE-IPSP to initiate the exchange, there is
no requirement to support switching of roles once an AS has been activated.
Permitting switching of roles in the fashion that you originally indicated
is problematic as follows:

    SE-IPSP1                    SE-IPSP2
        |                          |
        |-------ASPAC------------->|
        |                          |
        |<-------ASPIA-------------|
        |                          |
        |-------ASPIA------------->|
        |                          |
        |<-------ASPAC-------------|

	   ....  What now?  Is it active?  Inactive?

This is why, although either side may initiate the exchange, it should stick
with one role.

> support IPSP state machine as defined by the specifications.

If the IPSP is by definition just an ASP, then the exchange is perfectly
valid.  The IPSP actually has to act like an SGP to to respond to such
messages.

Also, to avoid the "glare" not handled by the RFC state machines, this is
a way to tell the other side not to change roles, or that its role is
unexpected.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 10 Nov 2005 09:43:23 -0500

Brian,

> Sent: Thursday, November 10, 2005 9:34 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Sorry to break my promise of not replying for this subtopic, but it
*is* required by it. You can't strip certain pieces of a state machine and
claim that you support it because certain pieces are not required. The state
machine allows it, so it is requried if you want to claim that your product
is fully complaint with it.
> no requirement to support switching of roles once an AS has been
[TOLGA]Take a look to the state machine, you re totally wrong. There are no
SGP/ASP roles assigned to IPSPs for the whole message exchange, that is the
reason why there an IPSP state machine.
> This is why, although either side may initiate the exchange, it
[TOLGA]Two points:
a)If there are open points -and I would think there may be some- in the IPSP
state machine, they can be fixed, this does not mean changing the whole
architecture.
b)For your example:
I assume initially AS in INACTIVE.
Because ASPAC from IPSP1 is not acknowledged with ASPAC-ACK AS states
INACTIVE.
With ASPIA from IPSPS2 AS state is INACTIVE
With ASPIA from IPSP1 AS state is INACTIVE
With ASPAC from IPSP2 AS is still INACTIVE. If IPSP1 replies with ASPAC-ACK,
AS will become ACTIVE.

For the above, we may need to clarify things in the IPSP state
machine -maybe introducing transitionary states-, but as said above this is
nowhere near to be a showstopper and does not require an architectural
change.

> valid.  The IPSP actually has to act like an SGP to to respond to such
[TOLGA]If IPSP were nothing else than ASP in terms of M3UA processing, we
wouldn't mention anything about it except the definition. The similarity
between IPSP and ASP is that they both host application logic, that is it.
>From M3UA state machine processing point of view, they are different
entities.
> a way to tell the other side not to change roles, or that its role is
[TOLGA]Now, you try to change the SE-IPSP model in the specification? ;-) To
support the model you want, you don't need to define anything new, just put
ASPF and SGPF together and there you are. If you don't want to use IPSP that
is fine.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Nov 2005 11:35:07 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 09:43:23)
> is fully complaint with it.

Huh? Compliance?  Where does it say that I must follow the state machine
illustrated in the RFC?  Also understand that the state machine is only
maintained at an SGP (or an IPSP that is acting like an SGP).  Also, the
transitions in brackets [] are not for SE-IPSP, only for DE-IPSP with
optional single-ended exchange, whatever that is.

> reason why there an IPSP state machine.

The state machine is only defined for an SGP to track the state of a remote AS
and MAY be used by an IPSP to track the state of an AS at a remote IPSP.  I
repeat MAY.  This is not a requirement.

> nowhere near to be a showstopper and does not require an architectural

We intentionally did not make changes over ASP/SGP communication.

> between IPSP and ASP is that they both host application logic, that is it.

Neither require application logic to be present.

> >From M3UA state machine processing point of view, they are different

For SE-IPSP the same state machine as that for the SGP is used.  The ASP
has no state machine.

> ASPF and SGPF together and there you are. If you don't want to use IPSP that

No.  It has always been this way.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 10 Nov 2005 13:42:36 -0500

Brian,

> Sent: Thursday, November 10, 2005 1:35 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]It is maintained at an IPSP as well:
"4.3.1 ASP/IPSP States

   The state of each remote ASP/IPSP, in each AS that it is configured to
   operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer
   IPSP, respectively). "
Actually they also need to be maintained by ASP, but this is another topic.

The transitions in brackets are not special for DE-IPSP case:

"4.3.1 ASP/IPSP States

[..snip..]
   The transitions are depicted as a result of the reception of ASP*M
   messages or other events. In some of the transitions there are some
   messages in brackets. They mean that for a given node the state
   transition will be different depending on its role: whether or not it
   is generating the ASP*M request message (i.e. ASPUP, ASPAC, ASPIA or
   ASPDN) or simply receiving it. In a peer-to-peer based architecture
   (IPSP), this role may change between the peers."

> repeat MAY.  This is not a requirement.
[TOLGA]Sorry, but it is a requirement, otherwise there is no way to know the
state of AS and to decide to allow traffic.
> We intentionally did not make changes over ASP/SGP communication.
[TOLGA]I know we tried not to change things significantly, but if there are
changes necessary they need to be done. It is obvious that we don't want to
use SGP/ASP state machines -existing IPSP state machine is not equivalent to
either one-, otherwise we wouldn't define anything called IPSP.
> Neither require application logic to be present.
[TOLGA]Form 1.2 Terminology:
   Application Server Process (ASP) - A process instance of an
   Application Server. An Application Server Process serves as an active
   or backup process of an Application Server (e.g., part of a
   distributed virtual switch or database).  Examples of ASPs are
   processes (or process instances) of MGCs, IP SCPs or IP HLRs.  An ASP
   contains an SCTP endpoint and may be configured to process signalling
   traffic within more than one Application Server.

BTW, please also note how the difference between ASP and IPSP explained, so
they are not the same because the behavior for M3UA stack is diffeerent for
each of them.

> No.  It has always been this way.
[TOLGA]Architecturally I am fine with the existing model, just needs some
cleanup/rewording/state machine polishing + extra text for not explained
topics.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 10 Nov 2005 12:17:05 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 13:42:36)
>    (IPSP), this role may change between the peers."

That is not RFC 3332 which is what we were discussing.

> either one-, otherwise we wouldn't define anything called IPSP.

We did not define an ASP state machine.

> they are not the same because the behavior for M3UA stack is diffeerent for

That IPSP definition is old and predates SE-IPSP.

--brian

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