Subject: RE: [Sigtran] Re: M3UA: Changeback Issue

From: "Bep Verberk"<[email-masked]>
Date: Thu, 14 Mar 2002 08:42:35 -0500

In priciple the potential here for mis-sequencing is no
different than in a pure TDM ss7 network. Assume that
the nodes Brian has labeled SG1, SG2, ASP1 and ASP2 are traditional
ss7 STP nodes and the destination is behind ASP1 and ASP2.
The CBA is sent from SG2 to SP with messages on their way from 
SG2 to ASP1/2. Now SP begins sending traffic to SG1. It is still
possible due to varying cross-office delays at SG1, ASP1, and ASP2
for missequencing to occur.

Granted with an IP network in the picture the probability of 
missequencing is higher, but I just wonder if adding this 
additional protocol complexity is worth while. Particularly
since its possible that there are multiple SS7 nodes between
SP and SG1/G2. For example if you insert serveral
STPs between SP and SG1/G2. The CB would be happening
between SP and a traditional STP, but the final path
to the ASPs due to this CB may end up being different and
result in the same potential for missequencing.

Cheers,
Bep

-----Original Message-----
From: Garnero, Pierre [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 3:37 AM
To: [email-masked]; Greg Sidebottom; [email-masked]
Subject: RE: [Sigtran] Re: M3UA: Changeback Issue

Brian,

Yes, I think that this problem must be fixed and I suppose that if it is
possible to use HEARTBEAT messages on a stream basis (and not only on stream
0), we could implement this mechanism with an already existing M3UA (ou SUA)
message (on receipt of the HEARTBEAT_ACK, we could consider that the
messages send (before the HEARTBEAT) on a particular stream have been
"flushed" and then received by the ASP). 
If I remember well, you have already proposed such a mechanism...

Cheers,

Pierre

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 9:18 PM
> To: Greg Sidebottom; [email-masked]
> Subject: [Sigtran] Re: M3UA: Changeback Issue
> 
> 
> Sigtraners,
> 
> We never corrected this problem with M3UA/SUA.  M3UA
> cannot support interworking with the SS7 network for
> multiple SGs and will fail Q.782 conformance tests
> pertaining to changeback.
> 
> Should this be corrected in the implementors guide?
> 
> --brian
> 
> On Wed, 11 Jul 2001, Brian F. G. Bidulock wrote:
> 
> > All,
> > 
> > M3UA does not provide support for the SS7 MTP changeback
> > procedure where multiple SG are involved.
> > 
> > Here is the scenario:
> > 
> > 
> >                +-------+        - - - - - 
> >                |       |       | /-----\ |
> >                |  SG1  |---------| ASP1|
> >               /| "STP" |\      |/\-----/ |
> >           A1 / |       | \     /
> >             /  +-------+  \   /|   AS    |
> >     /----\ /       |       \ /
> >     | SP |/        |        X  |  SPMC   |
> >     |    |\        |       / \
> >     \----/ \       |      /   \|         |
> >             \  +-------+ /     \
> >           A2 \ |       |/      |\/-----\ |
> >               \|  SG2  |---------| ASP2|
> >                | "STP" |       | \-----/ |
> >                |       |        - - - - -
> >                +-------+
> > 
> > The SP loses linkset A1.  Traffic is succesfully changed
> > over to linkset A2.  Linkset A1 restores.  SP peforms
> > changeback procedure per Q.704 6.2.1 (b) (i) (that is, on
> > a per-destination basis).  It sends a CBD for each SLS
> > which is being diverted from A2 back to A1 with a DPC of
> > the SPMC.
> > 
> > What is SG2 to do with the CBD?  If it responds with a CBA
> > there may be messages between SG2 and ASP1 or ASP2 which
> > have not yet arrived at the ASP and might be overtaken by
> > the diverted traffic.
> > 
> > The SG must have a message which it can send to the each
> > ASP which has the same effect as a changeback-declaration
> > which will be responded to by the ASP with a changeback-
> > acknowledgement so that mis-sequencing can be avoided
> > during changeback procedures per Q.704 6.2.1 (b)(i).
> > 
> > I can put together proposed text if anyone is interested.
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Mar 2002 13:41:11 -0600

Bep,

Bep Verberk wrote:                                            (Thu, 14 Mar 2002 08:42:35)
>    for missequencing to occur.

This is true for changeover.  In fact the specifications indicate
that an implementation might not want to use sequenced changeover
in some situations in some configurations, that it could use
time-controlled changeover instead.  That is not the case for
changeback.  Changeback has no missequencing possibility which
is inherent to the procedure.

>    result in the same potential for missequencing.

This is why changeback is an end-to-end (SEP to SEP) procedure.
There is no possibility of missequencing inherent to the
procedure.  This procedure is between the SPMC and the SS7
network.  Possibilities of missequencing between ASPs and SGPs
is addressed by draft-bidulock-sigtran-corrid-00.txt.

>    From: Garnero, Pierre [[1]mailto:[email-masked]]
>    Yes, I think that this problem must be fixed and I suppose that if it
>    is possible to use HEARTBEAT messages on a stream basis (and not only
>    on stream 0), we could implement this mechanism with an already
>    existing M3UA (ou SUA) message (on receipt of the HEARTBEAT_ACK, we
>    could consider that the messages send (before the HEARTBEAT) on a
>    particular stream have been "flushed" and then received by the ASP).
>    
>    > From: Brian F. G. Bidulock [[2]mailto:[email-masked]]
>    > > [3]http://www.openss7.org/
>    >
>    > --
>    > [4]http://www.openss7.org/ ¦ trying  to adapt the  world  to
>    himself. ¦
>    > [5]https://www1.ietf.org/mailman/listinfo/sigtran
>    >
>    
>    [6]https://www1.ietf.org/mailman/listinfo/sigtran
> 
> References
> 
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. http://www.openss7.org/
>    4. http://www.openss7.org/
>    5. https://www1.ietf.org/mailman/listinfo/sigtran
>    6. https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: Ken Morneault <[email-masked]>
Date: Thu, 14 Mar 2002 16:31:51 -0500

Brian,

I cannot find an example of SEP-to-SEP changeback in
the Q specs for the diagram you show.  Q.705 Section 
A.4.1.2 shows a changeback scenario that is consistent with 
Q.782 Test Case 4.8.  Further, Q.705 Section A.4.1.2 mentions
that mis-sequencing is possible if there is load sharing
on parallel links between the STPs.

Also, Section 6.3 of Q.704 talks of sending CBD to remote
signalling point of the signalling link, not to the destination SEP.
This means the CBD would be sent to the adjacent (the STP).

What am I missing?

Ken

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 14 Mar 2002 18:00:54 -0500

Hi,

In RFC2960 RECEIVE_UNSENT primitive does not have the context field (even
not as optional). This field might be very usefull to save us from redoing
(or doing in same ASP implementations) RK analysis, when we switchover to a
new association from a broken one. Was there a reason why it is not added or
just forgotten?

Another thing is, how is it possible to retrieve unsent messages by using
"Sockets API Extensions for SCTP" <draft-ietf-tsvwg-sctpsocket-03.txt>?

     Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Mar 2002 17:25:06 -0600

Ken,

Ken Morneault wrote:                                          (Thu, 14 Mar 2002 16:31:51)
> This means the CBD would be sent to the adjacent (the STP).

No, they are not sent to STPs.  Section 6.3.2 indicates that
the CBA is received from "the far signalling point" which "indicates
that all signal messages relating to the concerned traffic flow and
routed to the remote signalling point via the alternative signalling
links have been received."

This is the "far signalling point" and "remote signalling point"
not, as in the case of an STP, the "adjacent signalling point".

Also see 6.2.1(b) where at the signalling point's discretion it
can divert signalling traffic "individually for each traffic flow
(i.e., on destination basis)".  That is, the SEP performing
changeover can send CBD to each remote signalling point accessible
via the alternative signalling link for each SLS involved in the
changeback.

Q.705 Section A.4.1.2 is an example of Q.704 6.2.1(b)(ii), not an
example of Q.704 6.2.1(b)(i).

There is a note in Q.704 6.2.5 which mentions that time-controlled
diversion could be used for changeback between diferent link sets
or where multiple parallel changebacks cannot be performed.  But,
where the implementation is capable of Q.704 6.2.1(b)(i) procedure
where there is no possibility of missequencing, there is no need to
use time-controlled diversion except as a fallback should the sequenced
procedure fail.

On looking at Q.782 4.8 I see what you mean about Q.704 6.2.1(b)(ii)
being tested rather than Q.704 6.2.1(b)(i).  Nevertheless, operators
may require 6.2.1(b)(i) operation or at least non-time-controlled
diversion procedures in PICS/PIXIT.  (I know I used to...)

So, for example, the ETSI PICS ETS-300-008 Table A.13 item 13/4
provides for the option of always use time controlled procedure
when changing between linksets per Q.704-6.2.5, however, an operator
may have their own requirements restricting the use of this
optional procedure.  It is mandatory that the changeback initiation
and actions of 6.2 and sequence control procedure of 6.3 be supported.

So, in Q.782 4.8 and 4.9 how is the ASP/SPMC acting as SP A to send
CBD to SP C (SG2) via SP B (SG1)?

See also Note 4 at the bottom of test 4.8 "Stop traffic and check
that there were no lost mesages, no duplication an no missequencing."
Missequencing is not acceptable in this test case.

An that is not even dipping into the ASNI and GR-905-CORE specs which
may have even more onerous requirements.

It seems to me that giving the ASP a message to request the SG to
launch a CBD to a given destination on a given SLS with a given
CBC and receive an ACK would provide support for this situation in
all circumstances.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 14 Mar 2002 19:13:09 -0500

Hi,

Just now I noticed that data_retireval_id might be used in case of
switchovers for the purpose I mentioned in the message below (with the hope
that SCTP will send SEND FAILURE inidications for all of the unsent messages
and that cause code will contain enough information to tell whether it has
been attempted to send the message or not).
But in any case, my second question I still valid.

    Tolga

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Thursday, March 14, 2002 6:01 PM
> To: [email-masked]
> Subject: [Sigtran] SCTP: receiving unsend messages
>
>
> Hi,
>
>