Re: SE-IPSP definition
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
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.
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.
> >
> > 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.
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 protected]
http://www.openss7.org/