RE: SE-IPSP definition

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, November 10, 2005 1:35 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] SE-IPSP definition
>
>
> Tolga,
>
> Tolga Asveren wrote:
>                    (Thu, 10 Nov 2005 09:43:23)
> > Brian,
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > Sent: Thursday, November 10, 2005 9:34 AM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] SE-IPSP definition
> > >
> > >
> > > Tolga,
> > >
> > > Tolga Asveren wrote:
> > >                    (Thu, 10 Nov 2005 08:46:34)
> > > > >
> > > > > This message exchange is not required to be supported.
> > > > [TOLGA]Sorry but you are totally wrong. This is very well
> supported by
> > > > SE-IPSP state machine.
> > >
> > > It is not required by it.
> > [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.
>
> 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.
[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."



>
> > >
> > > 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.
> > [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.
>
> 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.
[TOLGA]Sorry, but it is a requirement, otherwise there is no way to know the
state of AS and to decide to allow traffic.
>
>
> > > 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.
> > [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.
>
> 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.
>
> >
> > >
> > > > >
> > > > > 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]->|
> > > > >        |                          |
> > > > [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.
> > >
> > > 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.
> > [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.
>
> 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.


   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.


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.

>
> > >From M3UA state machine processing point of view, they are different
> > entities.
>
> For SE-IPSP the same state machine as that for the SGP is used.  The ASP
> has no state machine.
>
> > >
> > > 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.
> > [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.
>
> 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.
>
> --brian
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>