RE: SE-IPSP definition
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
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. > > 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. > 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. > > > > > > > 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. >From M3UA state machine processing point of view, they are different entities. > > 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. > > --brian > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ >