Re: SE-IPSP definition

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 10 Nov 2005 13:42:36)
> >
> > 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."

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

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

We did not define an ASP state machine.

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

That IPSP definition is old and predates SE-IPSP.

--brian


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