Subject: [Sigtran] Seperate Layer Management for M3UA stack

From: naren k <[email-masked]>
Date: Tue, 24 Dec 2002 03:58:40 -0800 (PST)

Hi Brian,

Does each M3UA stack running at SGP has a seperate
layer management with in an SG??

Thanks & Regards,
-Naren.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 24 Dec 2002 12:07:00 -0700

naren,

It might, or it might not.  LM is implementation
dependent.  The LM "primitives" for M3UA are
just a suggestion.

--brian

naren k wrote:                                                                       (Tue, 24 Dec 2002 03:58:40)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 26 Dec 2002 06:40:10 -0600 (CST)

Brian and others,

How do we retreive messages from buffers of failed SCTP association?

Situations like loss of link will result in transmission and 
re-transmission of losed link, will be transfered to another link and
CHANGEOVER will takeplace...this is true ( MTP2 layer) in conventional
STP.

But How are we going to handle this scenarion with M3UA?

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 26 Dec 2002 04:51:05 -0800 (PST)

Samuel,
> How do we retreive messages from buffers of failed
[TOLGA] By calling the corresponding SCTP primitive.
If you don't want to loose/missequence/repeat any
message, then I think you have to look to corid draft
of Brian. But if you think, it is enough for you, you
can just retrieve unacknowledged and unsent messages
from SCTP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Dec 2002 13:13:02 -0700

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 26 Dec 2002 06:40:10)
> How do we retreive messages from buffers of failed SCTP association?

This depends on the SCTP implementation.

> But How are we going to handle this scenarion with M3UA?

M3UA does not handle this scenario.  draft-bidulock-sigtran-corid-00.txt
provides proceudres to avoid message mis-sequencing and message loss while
changing over between SCTP associations.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 26 Dec 2002 15:31:20 -0800 (PST)

Brian,
> Samuel,
> 
> Samuel Dur D. Jeyaseelan wrote:                     
>                                (Thu, 26 Dec 2002
> 06:40:10)
> > 
> > Brian and others,
> > 
[TOLGA]I wouldn't agree with the statement that M3UA
does not handle this scenario at all. If
missequencing/message loss/duplication is acceptable
to some degree, fetching unsent/unacknowledged
messages from SCTP and retransmitting them is not a
very bad choice (I agree that depending on IP network
delay, number of missequenced/loss/duplicate message
might increase, but from procedure point of view this
is similar to what happens with traditional SS7)

But I would think mentioning about procedures like
MTP3 forced rerouting/Controlled Rerouting procedures
in RFC/IG would be more explanatory. In fact even now,
there is a sentence in 4.1.1.
"In addition the message needs to be sent on the
appropriate SCTP stream, again taking care to meet the
message sequencing needs of the signalling
application."
IMO, this is not clear enough. I would think making
use of corid is better explained in an extension draft
(like it is now) but I think it is better to mention
about the above procedures in IG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Dec 2002 20:52:56 -0700

Tolga,

Tolga Asveren wrote:                (Thu, 26 Dec 2002 15:31:20)
> is similar to what happens with traditional SS7)

No, MTP has the changeover (and more importantly for
mis-sequencing, the changeback procedure).  M3UA has no
equivalent procedure.

Q.706 section 1.2:

	undetected errors: 1 in 10^10
	loss of messages: 1 in 10^7
	messages out-of-sequence (or duplication): 1 in 10^10

	Faiure response time (maximum permissible) 500 ms.
	Answer time to changeover order (maximum permissible): 300 ms.

Although it has been proven that this performance can be
acheived by MTP, M3UA leaves this responsibility to the
"implementation".  Yet, these is the performance that MTP Users
expect of the MTP (and therefore would expect of M3UA if M3UA is
to be transparent).

> about the above procedures in IG.

We agreed at LC that changeover/changeback would be handled by
extension draft.  The corid draft has been available for almost
a year now.

I think the IG should be used for corrections and clarifications
to the RFC and not to introduce new major functionality such as
changeover/changeback procedures.   As there has been no
objection to the corid procedures, why not just advance the
draft?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Dec 2002 05:12:35 -0700

Tolga,

> does not handle this scenario at all.

Although an SS7 implementation can clearly meet requirements
such as Q.706, it cannot be expected to exceed them.  Normally
the MTP to MTP-User interface duplicates zero (0) messages,
mis-sequences zero (0) messages, and loses zero (0) messages.
By adding message loss, mis-sequencing or duplication to the
MTP to MTP-User interface with M3UA, an MTP implementation
could easily no longer be able to meet these MTP performance
requirements.

By providing protocol (such as the corid draft), it is
possible to have any UA exhibit zero (0) message loss,
mis-sequencing and duplication.

Becase M3UA provides no such protocol or provisions, it does
not address this scenario.

Delegating Category (3) and (4) messages to SCTP does not
acheive this objective, as discussed in the corid draft.
Pure timer-based approaches does not acheive it either, as
SCTP exhibits unbounded delay.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 27 Dec 2002 05:32:08 -0800 (PST)

Brian,
> > > provides proceudres to avoid message
> mis-sequencing
> > > and message loss while
[TOLGA] In my opinion, M3UA does not need necessarily
changeover/changeback procedures (please note, I am
not saying it does not need corid, IMO a procedure
corresponding to corid does not exist in MTP3). For
M3UA, there is no case, which is corresponding to a
configuration, where there are multiple links between
two MTP3 entities and one of them fails. SCTP
association is there or not, multihoming is handled
within SCTP itself. Also a configuration where node A
can't reach node B but node C can reach it does not
sound very realistic to me in a properly engineered IP
network. For example also for SG-SG draft, for
communication between IP domain entities, I didn't
include changeover/changeback procedures.
> expect of the MTP (and therefore would expect of
[TOLGA] For that I agree, there might be IP networks,
where meeting those requirements just with RFC/IG is
not possible.
> extension draft.  The corid draft has been available
[TOLGA] As I mentioned above, IMO corid does not
correspond to changeover/changeback and does not have
a corresponding procedure in MTP3. Also there, it is
possible to loose/duplicate messages, if a host is
down or if the only link of a host is down. When
messages are fetched from MTP2, it gives
unacknowledged/unsent messages. But I agree that it is
still possible to meet requirements, because
propogation delay on a SS7 link is within predefined
bounds.
> objection to the corid procedures, why not just
[TOLGA]I also think that corid draft is usefull and I
hope we can see it as a WG item. My point is, time
controlled rerouting procedures are not a major change
(in fact I am sure most of the people have already
implemented them) and are better put to IG. They can
work without corid and are still usefull.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Dec 2002 07:13:04 -0700

Tolga,

Tolga Asveren wrote:                             (Fri, 27 Dec 2002 05:32:08)
> [TOLGA] As I mentioned above, IMO corid does not correspond to
> changeover/changeback and does not have a corresponding
> procedure in MTP3.
CORID corresponds to changeover/changeback for multiple SG in
M3UA, IPSP in all UAs, and even loosely for backhaul.

> Also there, it is possible to loose/duplicate messages, if a
> host is down or if the only link of a host is down.
It is not possible to duplicate messages in this case.

Also, MTP will never lose or duplicate messages across the
MTP/MTP-User interface, even in this case.

> When messages are fetched from MTP2, it gives
> unacknowledged/unsent messages.

That statement is misleading:

Not from the perpsective of the peer.  The changeover procedure
provides the peer's view of the last acknowledged message (the
ack of which the failed link perhaps did not succeed in
transferring).

Also, buffer updating in some circumstances only provides the
unsent messages (when clear RTB is signalled before retrieval).

> But I agree that it is still possible to meet requirements,
> because propogation delay on a SS7 link is within predefined
> bounds.

But it is probably not possible to exceed them to permit the
MTP/MTP-User interface to lose, duplicate or mis-sequence
additional messages (which it does not for SS7).

> > 
> > I think the IG should be used for corrections and
> > clarifications to the RFC and not to introduce new major
> > functionality such as changeover/changeback procedures.   As
> > there has been no objection to the corid procedures, why not
> > just advance the draft?
> [TOLGA]I also think that corid draft is usefull and I hope we
> can see it as a WG item. My point is, time controlled
> rerouting procedures are not a major change (in fact I am sure
> most of the people have already implemented them) and are
> better put to IG. They can work without corid and are still
> usefull.

They still permit additional message loss, duplication and
mis-sequencing between MTP and its Users which is unacceptable
when meeting SS7 performance requirements.  CORID provides a
mechanism which permits zero (0) message loss, duplication
and mis-sequencing across the UA, which is only way to guarantee
that the SS7 side of an SG can meet SS7 performance
requirements.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 28 Dec 2002 05:43:31 -0800 (PST)

Brian,
> correspond to
[TOLGA] IMO it does not. It is just another procedure,
which serves a similar purpose. With
changeover/changeback intiator is consulting the
destination. With corid, initiator sends some
additional info, so that multiple destinations can
handle the situation properly.
> ack of which the failed link perhaps did not succeed
[TOLGA] In a proper multihomed configuration, if SCTP
association is lost, I would assume with a very high
probability, peer is down or can't access the network
at all (or better said, can;t be accessed from oyther
IP nodes). So, IMO it is not very realistic to think
that one can get some information from the peer, to
which SCTP association is lost. IMO, the situation is
similar to what happens in SS7, when the peer is down,
the only information you have is the local one.
> additional messages (which it does not for SS7).
[TOLGA] For that I agree. Depending on the
characteristics of the IP network, it might be
possible to exceed this limit with M3UA.
> that the SS7 side of an SG can meet SS7 performance
[TOLGA] Time controlled procedures won't assure 0
message loss/duplication/missequencing but they for
sure will improve the quality and what is needed is
just a few sentences in IG.
For corid, as I mentioned before, I think it is
usefull, although I also believe no procedure can 100%
assure no message loss/duplication/missequencing. But
of course, corid might help to reduce this number. The
real quality will depend on synchronization between
ASPs.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 28 Dec 2002 17:09:33 -0700

Tolga,

Tolga Asveren wrote:                                (Sat, 28 Dec 2002 05:43:31)
> > > changeover/changeback and does not have a corresponding procedure in
> > > MTP3.
> > CORID corresponds to changeover/changeback for multiple SG in M3UA, IPSP
> > in all UAs, and even loosely for backhaul.
> [TOLGA] IMO it does not. It is just another procedure, which serves a
> similar purpose. With changeover/changeback intiator is consulting the
> destination. With corid, initiator sends some additional info, so that
> multiple destinations can handle the situation properly.

Nevertheless, it does: it is even stated so in the draft.

> > 
> > > Also there, it is possible to loose/duplicate messages, if a host is
> > > down or if the only link of a host is down.
> > Also, MTP will never lose or duplicate messages across the MTP/MTP-User
> > interface, even in this case.
> > 
> > > When messages are fetched from MTP2, it gives unacknowledged/unsent
> > > messages.
> > 
> > Not from the perpsective of the peer.  The changeover procedure provides
> > the peer's view of the last acknowledged message (the ack of which the
> > failed link perhaps did not succeed in transferring).
> [TOLGA] In a proper multihomed configuration, if SCTP association is lost, I
> would assume with a very high probability, peer is down or can't access the
> network at all (or better said, can;t be accessed from oyther IP nodes). So,
> IMO it is not very realistic to think that one can get some information from
> the peer, to which SCTP association is lost. IMO, the situation is similar
> to what happens in SS7, when the peer is down, the only information you have
> is the local one.

Bad assumption.  SCTP places no such requirements on the underlying network.
In general, any path in an IP network can be unavailable, while other paths
are available: otherwise SCTP would never need multi-homing.

> > 
> > Also, buffer updating in some circumstances only provides the unsent
> > messages (when clear RTB is signalled before retrieval).
> > 
> > > But I agree that it is still possible to meet requirements, because
> > > propogation delay on a SS7 link is within predefined bounds.
> > 
> > But it is probably not possible to exceed them to permit the MTP/MTP-User
> > interface to lose, duplicate or mis-sequence additional messages (which it
> > does not for SS7).
> [TOLGA] For that I agree. Depending on the characteristics of the IP
> network, it might be possible to exceed this limit with M3UA.

If the MTP already meets this limit, M3UA will exceed it.

> > 
> > > > 
> > > > I think the IG should be used for corrections and clarifications to
> > > > the RFC and not to introduce new major functionality such as
> > > > changeover/changeback procedures.   As there has been no objection to
> > > > the corid procedures, why not just advance the draft?
> > > [TOLGA]I also think that corid draft is usefull and I hope we can see it
> > > as a WG item. My point is, time controlled rerouting procedures are not
> > > a major change (in fact I am sure most of the people have already
> > > implemented them) and are better put to IG. They can work without corid
> > > and are still usefull.
> > 
> > They still permit additional message loss, duplication and mis-sequencing
> > between MTP and its Users which is unacceptable when meeting SS7
> > performance requirements.  CORID provides a mechanism which permits zero
> > (0) message loss, duplication and mis-sequencing across the UA, which is
> > only way to guarantee that the SS7 side of an SG can meet SS7 performance
> > requirements.
> [TOLGA] Time controlled procedures won't assure 0 message
> loss/duplication/missequencing but they for sure will improve the quality
> and what is needed is just a few sentences in IG.  For corid, as I mentioned
> before, I think it is usefull, although I also believe no procedure can 100%
> assure no message loss/duplication/missequencing. But of course, corid might
> help to reduce this number. The real quality will depend on synchronization
> between ASPs.

On the contrary, it is rather trivial for a procedure to provide 100%
assurance of no message loss/duplication/missequencing: SCTP (and TCP and
others for that matter) already provide this within a connection; SCTP even to
multiple destinations.  With sequence numbering (correlation id) and
retransmission, it is as easy to acheive 0 message loss/duplication/
missequencing between associations as it is within an association.  This is
what the CORID draft provides that M3UA does not: 0 message loss, duplication
and missequencing.

In fact, it is the time procedures you wish to place in the IG (which are only
a fallback for CORID just as they are only a fallback for SS7) that cannot
guarantee 100% reliable transport from SG to AS.  The sequenced procedures of
CORID *do* guarantee 100% reliable transport from SG to AS.

So what's the point in placing stuff in the IG about this, to only marginally
increase M3UA transport reliability without providing the means to meet MTP
performance objectives?  All that will result is an M3UA which still does not
adequately address failover between associations.

It would be about as useless as trying to address peer-to-peer in the IG.  The
IG needs to be released to correct and clarify things in the RFC, not to add
new major functionality.  Such things are better addressed in a draft of their
own (and have been).

I will resubmit updated extension drafts shortly.  Although they were written
and sumbitted a year ago, it appears that only now has interest in them
appeared.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 28 Dec 2002 17:09:33 -0700

Tolga,

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 29 Dec 2002 17:36:37 -0800 (PST)

Brian,
> additional info, so that
[TOLGA]IMO still it does not. corid addresses host
failures(including NIC failures), which are not
handled for SS7 and which could be a problem for M3UA
depending on the IP network characteristics.
> are available: otherwise SCTP would never need
[TOLGA] For that I have two comments. First, unless
multihomed addresses are using totaly different
networks, I doubt whether it can address network
problems. 
Secondly -and more importantly-, SCTP multihoming is
not very related with my assumption. My assumption is,
in a properly engineered IP network if endnode A can't
reach endnode B but can reach endnode C then also
endnode C can't reach endnode B. That all of tose
nodes have interaces to two separate networks does not
change too much.
Now, if you say that this assumption is not
realistic/correct then what is needed is the exact
equivalent of changeover/changeback procedures, not
corid procedures, because corid assumes some
implementation dependent communication between ASPs.
This communication is necessary if one wants to
address host failures.

> message
> assurance of no message
> loss/duplication/missequencing: SCTP (and TCP and
[TOLGA] I don't think it is a good idea to compare
message loss in TCP with message loss on a distributed
system. For example even with corid message
loss/duplication is possible. How can one assure that
the last synchronization message received from a peer
is actually the last one, this peer has processed and
delivered to user part before ? IMO, quality with
corid depends heavily on the communciation mechanism
between ASPs, which is implementation dependent.
> adequately address failover between associations.
[TOLGA] The point, why time controlled procedures
might be added to IG is, because they can work
independently from corid procedures, and can decrease
chances for missequencing when switching between
peers. What is needed is just a few sentrences in IG. 
> addressed in a draft of their
[TOLGA] I don't propose to address peer-to-peer in IG.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 29 Dec 2002 21:37:17 -0700

Tolga,

Tolga Asveren wrote:                            (Sun, 29 Dec 2002 17:36:37)

[snip]
> > 
> > Bad assumption.  SCTP places no such requirements on the underlying
> > network.  In general, any path in an IP network can be unavailable, while
> > other paths are available: otherwise SCTP would never need multi-homing.
> [TOLGA] For that I have two comments. First, unless multihomed addresses are
> using totaly different networks, I doubt whether it can address network
> problems. 
> Secondly -and more importantly-, SCTP multihoming is not very related with
> my assumption. My assumption is, in a properly engineered IP network if
> endnode A can't reach endnode B but can reach endnode C then also endnode C
> can't reach endnode B. That all of tose nodes have interaces to two separate
> networks does not change too much.
> Now, if you say that this assumption is not realistic/correct then what is
> needed is the exact equivalent of changeover/changeback procedures, not
> corid procedures, because corid assumes some implementation dependent
> communication between ASPs.  This communication is necessary if one wants to
> address host failures.

Several remarks:

First, completely separate networks are not necessary: just some (actually
any) redundancy built into the network.

Second, it is often possible that endpoint A can't reach endnode B but can
reach endnode C.  All it takes is for some non-common element (in the path
from A to B, but not from B to C or A to C) to fail.  That does not have to be
host failure or NIC failure: it could be the failure of a non-common Ethernet
rail or router(s) in the network.  That's why it is a bad assumption.

Last, the UAs assume an implementation dependent communication between ASPs.
Otherwise, they could not handle fail-over in the first place (call and
transaction state would be lost).  Therefore it is not unreasonable for CORID
to assume the existence of the mechanism which the UAs themselves assume is
present for proper operation.  Also, M3UA in particular comes very close to
requiring that SGP in an SG communicate with each other (to be able to
transfer messages between SGP under failure scenarios).  Again, is is not
unreasonable for CORID to assume that SGP within the same SG can communicate.

Note that the 'P' in ASP and SGP stands for "Process", not "Host".  If you
presume that ASP and SGP map onto "Host" then you have already restricted
the model.

> > others for that matter) already provide this within a connection; SCTP
> > even to multiple destinations.  With sequence numbering (correlation id)
> > and retransmission, it is as easy to acheive 0 message loss/duplication/
> > missequencing between associations as it is within an association.  This
> > is what the CORID draft provides that M3UA does not: 0 message loss,
> > duplication and missequencing.
> [TOLGA] I don't think it is a good idea to compare message loss in TCP with
> message loss on a distributed system. For example even with corid message
> loss/duplication is possible. How can one assure that the last
> synchronization message received from a peer is actually the last one, this
> peer has processed and delivered to user part before ?

No problem (read the CORID draft) because every message is labelled with a
sequence number (correlation id), if the peer has already processed this
message then it is discarded.

This is in practice no different than what TCP or SCTP does, except that it
is done across associations rather than within.  How does SCTP know that it
has not already processed a message?  By its sequence number, of course.

> IMO, quality with corid depends heavily on the communciation mechanism

As the ASPs need to synchronize call and transaction state anyway, this is
not a problem.  One simple sequence number per AS (in contrast to thousands
of circuit states and thousands of transaction states).

> > 
> > In fact, it is the time procedures you wish to place in the IG (which are
> > only a fallback for CORID just as they are only a fallback for SS7) that
> > cannot guarantee 100% reliable transport from SG to AS.  The sequenced
> > procedures of CORID *do* guarantee 100% reliable transport from SG to AS.
> > 
> > So what's the point in placing stuff in the IG about this, to only
> > marginally increase M3UA transport reliability without providing the means
> > to meet MTP performance objectives?  All that will result is an M3UA which
> > still does not adequately address failover between associations.
> [TOLGA] The point, why time controlled procedures might be added to IG is,
> because they can work independently from corid procedures, and can decrease
> chances for missequencing when switching between peers. What is needed is
> just a few sentrences in IG. 

The time controlled procedures are described in the CORID draft, and have
not been formally described elsewhere.  It makes little sense to me to extract
a minor part of the CORID procedure (the fallback procedure) out of the draft
and place it in the IG.  It is the sequenced procedures that provide value
(0 message loss/.../...), not the fallbacks.

> > 
> > It would be about as useless as trying to address peer-to-peer in the IG.
> > The IG needs to be released to correct and clarify things in the RFC, not
> > to add new major functionality.  Such things are better addressed in a
> > draft of their own (and have been).

But you are proposing to address CORID in the IG, which is about the same
thing.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 30 Dec 2002 03:41:55 -0800 (PST)

Brian,
> realistic/correct then what is
> implementation dependent
[TOLGA] I agree. So, in this case not the SCTP
multihoming but IP network redundancy is the solution
to address network failures.
> rail or router(s) in the network.  That's why it is
[TOLGA] I wouldn't build a IP network where this
assumption is not true, although I agree that
theoretically the assumption might not hold. I also
would try not to have a single point of failure in the
core. Still, IMO this is one of the "undocumented"
assumptions behind the architecture. Especially for
two tightly coupled ASPs, I would expect this
assumption to hold: If you can't reach one of them but
can reach the other one, then the former one is either
down or completly isolated from the IP network.
> presume that ASP and SGP map onto "Host" then you
[TOLGA] I don't have any problem that corid requires
communication between ASPs (or SGPs). In fact, this
probably is the only way, if one wants to address host
failures or total isolation from the network. My point
is, if there is a need to address network failures
(IMO, there isn't, it belongs to IP redundancy), I
personally would go with an approach similar to
changeover/changeback.
> message then it is discarded.
[TOLGA] That is exactly my question. What will happen
if the peer processes the message and delivers it to
the user part but fails to inform about its
correlationId, before it goes down? If one does this
synchronization with every message, then one can limit
the loss/duplication to 1 message. If one does this
synchronization with every 10 message, then in the
worst case one can loose/duplicate 10 messages.
> But you are proposing to address CORID in the IG,
[TOLGA]I don't propose to address corid in IG, just
time controlled procedures, because they are
independent of corid procedure itself. But O.K., it is
your draft, so leave it where you want.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 30 Dec 2002 13:18:43 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 30 Dec 2002 03:41:55)
> [TOLGA] I agree. So, in this case not the SCTP multihoming but IP network
> redundancy is the solution to address network failures.

No.  Redundancy can be such that SCTP multihoming is still necessary.

> > from A to B, but not from B to C or A to C) to fail.  That does not have
> > to be host failure or NIC failure: it could be the failure of a non-common
> > Ethernet rail or router(s) in the network.  That's why it is a bad
> > assumption.
> [TOLGA] I wouldn't build a IP network where this assumption is not true,
> although I agree that theoretically the assumption might not hold. I also
> would try not to have a single point of failure in the core. Still, IMO this
> is one of the "undocumented" assumptions behind the architecture. Especially
> for two tightly coupled ASPs, I would expect this assumption to hold: If you
> can't reach one of them but can reach the other one, then the former one is
> either down or completly isolated from the IP network.

Particularly where ASPs are closely coupled this is not necessarily the case.
The only thing required is a separate path between ASPs and the greater IP
network, which is common in closely coupled arrangements.

> > 
> > Last, the UAs assume an implementation dependent communication between
> > ASPs.  Otherwise, they could not handle fail-over in the first place (call
> > and transaction state would be lost).  Therefore it is not unreasonable
> > for CORID to assume the existence of the mechanism which the UAs
> > themselves assume is present for proper operation.  Also, M3UA in
> > particular comes very close to requiring that SGP in an SG communicate
> > with each other (to be able to transfer messages between SGP under failure
> > scenarios).  Again, is is not unreasonable for CORID to assume that SGP
> > within the same SG can communicate.
> > 
> [TOLGA] I don't have any problem that corid requires communication between
> ASPs (or SGPs). In fact, this probably is the only way, if one wants to
> address host failures or total isolation from the network. My point is, if
> there is a need to address network failures (IMO, there isn't, it belongs to
> IP redundancy), I personally would go with an approach similar to
> changeover/changeback.

There is also a need to address recovery and planned maintenance turn-down.
Neither of these are properly address by timed procedures, as the sequenced
procedures provide for zero loss under these situations.

> [TOLGA] That is exactly my question. What will happen if the peer processes
> the message and delivers it to the user part but fails to inform about its
> correlationId, before it goes down? If one does this synchronization with
> every message, then one can limit the loss/duplication to 1 message. If one
> does this synchronization with every 10 message, then in the worst case one
> can loose/duplicate 10 messages.

It is no different for call and transaction state.  It *is* possible to
perform atomic actions in distributed systems, and zero message loss is
possible.

> > not a problem.  One simple sequence number per AS (in contrast to
> > thousands of circuit states and thousands of transaction states).
> > 
> [TOLGA]I don't propose to address corid in IG, just time controlled
> procedures, because they are independent of corid procedure itself. But
> O.K., it is your draft, so leave it where you want. 

Thank you.

--brian