Subject: Re: [Sigtran] recommendations for M3UA/SUA BEATs when running over SCTP

From: Michael Tuexen <[email-masked]>
Date: Sat, 1 Oct 2005 21:01:36 +0200

Hi Jeff,

if the receiving SCTP endpoint gives you an a_rwnd = 0 the application 
is
too slow to handle all traffic. Sending application level HB does not 
help here,
it hurts because it puts even more messages on the receiver.

I think the sender has to supervise its sending queue and start some 
application
level flow control mechanisms like sending SIBs to its local user in 
the SS7 world.

So I think not sending these messages AND supervising the send queue is 
the way to go.

Best regards
Michael

On Sep 30, 2005, at 20:41 Uhr, Jeff Morriss wrote:

>
> Hi list,
>
> Neither the M3UA nor the SUA RFC recommend sending BEATs when used 
> over SCTP.  ETSI goes a bit further and precludes the use of BEATs.
>
> However, SCTP (in particular, the I-G) allows the association to get 
> "stuck" such that it will pass no data: a receiver is allowed to hold 
> its window closed "for an indefinite time" (new text for section 6.1 
> A).
>
> I have encountered a number of problems in peer SCTPs which have 
> caused those peers to close their windows and keep them closed 
> indefinately. This leads to very serious traffic loss since M3UA will 
> continue to queue mesages to the "stuck" association until the queues 
> fill up and/or overflow.
>
> Using an end-to-end health check mechanism (such as M3UA or SUA BEATs) 
> solves this problem pretty nicely (similar to the way periodic SLTMs 
> do in MTP3).  However, I suspect many M3UA/SUA implementors may not 
> implement or may not turn on (by default) BEATs under the (false, due 
> to the reasons listed above) pretense that SCTP heartbeats are 
> sufficient to ensure the viability of the association.
>
> What to do?  Should the RFCs recommend (or even require) using BEATs, 
> even when run over SCTP?  (This is just a recommendation change for 
> the RFCs but is a complete reversal for ETSI--but I guess that's not 
> this list's problem.)
>
> Regards,
> -Jeff
>
> _______________________________________________
> 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: Jeff Morriss <[email-masked]>
Date: Mon, 03 Oct 2005 10:12:02 -0400

Hi Michael,

Michael Tuexen wrote:
> Hi Jeff,
> 
> if the receiving SCTP endpoint gives you an a_rwnd = 0 the application is

Actually the application is fine.  In fact I believe, in this case, it 
has a second assoc which is in good shape.  It's just got one assoc 
which is "stuck."

> level flow control mechanisms like sending SIBs to its local user in the 
> SS7 world.
> 

The problem then becomes one of detecting when congestion gets to be 
"too much."  I guess a timer is needed.

Regards,
-Jeff

>> its window closed "for an indefinite time" (new text for section 6.1 A).
>>

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 03 Oct 2005 10:29:40 -0400

Hi Brian,

Brian F. G. Bidulock wrote:
> Jeff,
> 
> Jeff Morriss wrote:                                                                   (Fri, 30 Sep 2005 17:35:49)
> 
>>Hi Brian,
>>
>>Brian F. G. Bidulock wrote:
>>
>>>Jeff,
>>>
>>>Jeff Morriss wrote:                         (Fri, 30 Sep 2005 14:41:35)
>>>
>>>
>>>>Hi list,
>>>>
>>>>Neither the M3UA nor the SUA RFC recommend sending BEATs when used over 
>>>>SCTP.  ETSI goes a bit further and precludes the use of BEATs.
>>>>
>>>No, no, no.  SCTP is not permitted to hold its window closed
>>>indefinitely just for the sake of it.  Only while its receive buffer is
>>>indeed full and the user is not servicing it.  This was always the case
>>>for SCTP.  The IG merely adds the zero window probe procedure to keep
>>>the sender from stalling if the data happens to be unidirectional and
>>>SACKs are being lost from the receiver.
>>
>>RFC 2960 doesn't specifically mention that the receiver is allowed to 
>>hold it closed indefinitely while the I-G specifically mentions it:
>>
>>~~
>>       If the sender continues to receive new packets from the receiver
>>       while doing zero window probing, the unacknowledged window probes
>>       should not increment the error counter for the association or any
>>       destination transport address.The reason is that the receiver MAY
>>       keep its window closed for an indefinite time.  Refer to
>>~~
>>
>>(more below)
> 
> 
> Because the application is stuck.

No, the application is fine.  But (one of) the SCTP assocs it is using 
is stuck (due to a bug or whatever).

>>>Also, this has nothing to do with UA BEATs.  The UA BEAT message cannot
>>>arrive at the peer UA if the peer UA is not servicing its receive buffer
>>>and the buffer is full (rwnd = 0).
>>
>>Yes, that's exactly the point.  If the BEATs fail that means the assoc 
>>isn't carrying traffic.
>>
>>
>>>>I have encountered a number of problems in peer SCTPs which have caused 
>>>>those peers to close their windows and keep them closed indefinately. 
> 
> 
> There is no point in sending the messages.  SCTP provides a lifetime
> capability at the sender which allows the association to be aborted
> if a message ages in the send buffer beyond an interval.  Use that
> instead if you simply want to abort when the receiver sticks.
> 
> 
>>>
>>>Not a recommended practice.  Some implementations might artificially
>>>adjust rwnd.  This is not correct, and has been counter-recommended on
>>>TSVWG many times.  The only reason for closing rwnd is the actually
>>>filling of the receive buffer.  Anything else is an incorrect indication
>>>to the peer and any resulting performance or reliability problem is the
>>>fault of the SCTP implementation artificially closing the window.
>>
>>That's all well and good, but "problems" (read: bugs) do crop up and 
>>"the system" should be able to detect the problem, reset, and keep going 
>>(or at least try real hard to do so).
> 
> 
> A similar bug in SS7 would cause problems too.  

Hmmm, I'm not so sure...

MTP2 has T7 whose expiry will kill the link for excessive delay of ACK 
and T6 which will kill the link due to excessive congestion.  SCTP has 
neither, though it does, as you say, have an optional (and barely 
documented) data lifetime.  (I'll have to look at how many SCTPs 
implement that...)

MTP3 has (optional) periodic SLTMs in case those two MTP2 safeguards 
fail.  M3UA has (optional) BEATs but doesn't recommend them; neither 
does it recommend using SCTP's lifetime feature.

These differences mean, to me, that M3UA (as specified) has a big hole 
in it (through which someone could drive several hundred thousand call 
failures).

 > For SS7, validation and
> interworking testing is performed to ensure that the protocol stacks are
> not so poorly designed.

No amount of testing and validation will uncover every single bug in the 
system.  (And I do hope the above was a typo and you do you know the 
difference between a bug and a design problem.)

>>>>This leads to very serious traffic loss since M3UA will continue to 
>>>>queue mesages to the "stuck" association until the queues fill up and/or 
>>>>overflow.
>>>
>>>
>>>The sending M3UA can always monitor its send buffer occupancy to such a
>>>peer and respond accordingly.  If you look at the same ETSI spec that
>>>did away with BEATs, it also says that congestion procedures must be
>>>implemented.  An M3UA SG queuing messages to such a stuck ASP would,
>>>when following ETSI, have to indicate congestion back to the SS7 network
>>>or other sending ASPs.
>>>
>>>Then queues neither fill up, nor overflow.
>>
>>True, but what if the window being closed is due to a bug in the peer 
>>and that peer won't ever recover until the assoc is reset (read: is torn 
>>down and gets a fresh start on life)?
> 
> 
> So abort it.  Set a lifetime or a buffer threshold to abort.  But your
> still going to loose all buffered messages or risk duplicating them if
> you don't follow the corrid procedures.

I'll look into that.  But should the RFCs be updated to have some kind 
of recommendation?  I'd hate for other people/implementations to run 
into the same problem (isn't that part of what recommendations are for?).

>>>>solves this problem pretty nicely (similar to the way periodic SLTMs do 
>>>>in MTP3).
>>>
>>>
>>>SLTMs do not do this.  They are for detecting circuit assignment
>>>problems more than anything else.  A link will should never be taken
>>>down from a failure to acknowledge an SLTM due to queuing delay.  I have
>>>see cascading network failures from the failure to follow this
>>>principle.
>>
>>As per above, we're not talking about congestion nor queuing delay. 
>>We're talking about a "stuck" assoc.  Those BEATs/SLTMs will _never_ be 
>>responded to; in MTP3 2 such failures will cause the link to be failed 
>>(T1.111.7 section 2.2).
> 
> 
> No.  Not while in service, only during activation.  It is optional to
> even send SLTM while in service.

Agreed (that's why I specified that I was talking about periodioc 
SLTMs).  But MTP3 can afford to make that optional since MTP2 has T6 and T7.

> I remember in the early days of SS7 the switch line modules used to
> nicely send an echo SLTMs even though MTP on the front-end was dead.
> Sending heartbeats does not cure anything.  Proper design of the
> application does.

Sounds like that MTP was poorly designed; there's no point in having 
health checks if they're responded to by the wrong layer.

>>>>However, I suspect many M3UA/SUA implementors may not implement or may
>>>>not turn on (by default) BEATs under the (false, due to the reasons
>>>>listed above) pretense that SCTP heartbeats are sufficient to ensure
>>>>the viability of the association.
> 
> 
> SCTP heartbeats do ensure the viability of the SCTP association.  If an
> application fails, yet does so without closing the association, it is
> simply in error.  I don't see the need for the end operating correctly
> to compensate for the end operating in error.

So that there are never, ever, sustained call failures?  Or at least not 
avoidable ones?

If SIGTRAN hopes to be as reliable as SS7, "the other side is broke, 
it's their problem" is the wrong attitude to have.

(And again: the application is fine.  But one assoc is stuck.)

> Nevertheless, set a lifetime on each sent message.  Abort the
> association if a lifetime expires without being acknowledged by SCTP
> and consult the corrid draft for how to handle messages in transit.
> 
> 
>>>
>>>If you follow ETSI's congestion requirements you will not have a
>>>problem.  (Note that the BEATs will not get through under those
>>>conditions anyway.)
>>
>>Except that the bug has now caused the peer to be permanently congested 
>>(unless there's a failure due to excessive congestion--I haven't checked).
> 
> 
> Which is precisely why congestion should be signalled, so the rest
> of the network can avoid sending to the overloaded component.

But it still misses the point that the application itself is _not_ 
congested.  It could even have a second assoc which is perfectly fine. 
Congestion would tell the network to stop sending to the application 
(meaning few if any calls would go through); that could actually be 
worse than the current problem which, if the application had, say, 2 
(loadshared) assocs would "only" lead to 50% call failure.

A timer guarding the congestion would solve all that, so that's probably 
the way to go.

>>>>even when run over SCTP?  (This is just a recommendation change for the 
>>>>RFCs but is a complete reversal for ETSI--but I guess that's not this 
>>>>list's problem.)
>>>
>>>
>>>Just implement congestion control.  Also if you have an alternative ASP
>>>or SGP (e.g. in a loadsharing arrangement) switch over to that.  When
>>>switching traffic, use the proceedures of draft-bidulock-sigtran-corrid
>>>and you will avoid message loss or duplication, even to a non-corrid
>>>aware host (but to use all the corrid procedures you must be able to
>>>send BEATs).
>>
>>I suppose that the peer being marked as congested will certainly raise 
>>alarms throughout the network (which would at least make the problem 
>>visible to everybody, not just the adjacent node) but in my experience, 
>>there are a fair number of bugs which can be automatically (no manual 
>>intervention--which may not arrive for several hours) fixed by simply 
>>resetting the troubled thing.  Unless there is an "excessive congestion" 
>>clause, this won't help.
> 
> 
> So set lifetime and abort the assocation.  But that is surely not only
> implementation dependent but is an operational consideration that has
> not place in the protocol specification.

Hmmm, I disagree.  Reading the specs would lead one to believe that one 
is reasonably safe in letting SCTP manage the viability of the assocs 
(and M3UA's ability to send data on them).  This could lead implementors 
to ignore this potential problem until they run into it.

(But obviously it's not my call; I just thought people here might be 
interested...)

Regards,
-Jeff

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Oct 2005 11:14:59 -0600

Jeff,

Jeff Morriss wrote:                                                                   (Mon, 03 Oct 2005 10:29:40)
> is stuck (due to a bug or whatever).

Splitting hairs.  Either the SCTP implementation of appplication are
broken.  Fix them.

> documented) data lifetime.  (I'll have to look at how many SCTPs 

No.  T7 is equivalent to the SCTP RTO.  In your situation the messages
have passed SCTP and been delivered to the user (receive buffer).  The
user is not collecting them.

If an SS7 link acknowledges messages and places them in the RB and the
MTP3 does not collect them and local processor outage is not signalled,
the same thing will occur.  There would be no T7 to expire.  The
implementation might SIB at some point, but that would be implementation
dependent.

Careful and correct design (and, yes, of course, accurate realization)
ensures that this cannot happen.  SS7 Level 2 does not acknowledge
message until they have actually been delivered to MTP3, not just the
receive buffer.

If you need such an acknowegement, use CorrelationId/CorrelationId Ack
in M3UA.

> fail.

SLTM is not used in this way.

> M3UA has (optional) BEATs but doesn't recommend them; neither 

BEATs are more useful for flushing data, like COO/COA, CBD/CBA.
See the corrid draft.

> in it (through which someone could drive several hundred thousand call 

I disagree.  I also agree with Michael.  BEAT should not be used in this
fashion.

> difference between a bug and a design problem.)

If you know the difference between one kind of defect and another, perhaps
you know the difference between validation testing and ad hoc testing.

> into the same problem (isn't that part of what recommendations are for?).

That's what this mailing list is for.  I also doubt that anyone else has
your application sticky bug problem.

> SLTMs).  But MTP3 can afford to make that optional since MTP2 has T6 and T7.

Yes, and SCTP provids M3UA with many ways to monitor the health and
performance of an SCTP association.  You can even retrieve the SRTT,
current RTO, congestion window and others that MTP3 cannot do from MTP2.

At what level of degradation of the association the application wishes
to abort it is an operational consideration that will vary from application
to application, network to network, and operator to operator.

If it is USSD e-mail that is being transferred, I might not care if the
application sticks until Tuesday.  If it is an ISUP call setup, I might
care if it sticks for more than two seconds.

Set your SCTP lifetimes accordingly.

> health checks if they're responded to by the wrong layer.

You do not understand the SLTM.  It is not intended to be used to check
the health of MTP3.  It is intended to be used to check for digital
cross connect and loopback problems.

If you ever worked with SS7 you might know that an MTP Level 2 link will
align nicely against itself if you loop back transmit onto receive.  The
mistaken presence of a loopback on an SS7 circuit could endanger an STP
or SP aligning links, particularly during emergencies where a
significant level of traffic would otherwise be applied to the link.

The SLTM detects loopbacks on links and is performed just after
alignment and will fail the link if a loopback is detected.

Another common cross-connect problem is attaching the transmit of one
SS7 link to the receive of the other.  Another is connecting the wrong
links in a linkset to each other (that will cause problems with a
changeover, changeback or other link management is performed).  SLTM
detects these cross-connect problems too.

STLM could be performed periodically as well to detect cross-connect
problems that occurred that did not cause the link to fail, but, because
it is very unlikely that a cross-connect change would leave the SS7 link
standing, taking the link out of service due to a periodic SLTM is not
done.  It is more likely that the SLTM just got delayed.  If a
cross-connect change is made while the link is in service, it will
fail and the cross-connect problem will be discovered by the SLTM if
the link can still successfully align.  Most switches only generate a
minor alarm condition if a periodic SLTM fails.

Your insistence on BEAT is similar.  If your M3UA data messages are
stuck between M3UA and the application, BEAT will not detect that,
because it will be responded to below the blockage.  If the blockage is
below that, the BEAT will also be delayed.

Use SCTP lifetimes or the other mechanisms afforded by SCTP to monitor
that that grade of service of the association meets your expectations.

> So that there are never, ever, sustained call failures?  Or at least not 

What you consider an avoidable failure by resetting an association, a
correct implementation sees as an unnecessary failure (of the
association).

> it's their problem" is the wrong attitude to have.

But that is SS7's attitude.  Attitude and reliability it seems have
nothing to do with each other.

> congested.

Yes it is.  Due to a bug maybe, but it is congested.

> to ignore this potential problem until they run into it.

Read the SCTP Applicability RFC.

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 20:11:06 +0200

Hi Jeff,

see my comments in-line.

Best regards
Michael

> has a second assoc which is in good shape.  It's just got one assoc 
This means that you have a broken SCTP implementation. What does is 
mean in particular:
Does the SCTP SACK everything but does not deliver things? Does it stop 
SACKing?
>> So I think not sending these messages AND supervising the send queue 
>> is the way to go.
>
As far as I understand things, I would supervise the SCTP send queue 
and depending on the
size perform similar actions as in the SS7 case.
>>> "stuck" such that it will pass no data: a receiver is allowed to 
>>> hold its window closed "for an indefinite time" (new text for 
>>> section 6.1 A).
>>>
>>> indefinately. This leads to very serious traffic loss since M3UA 
>>> will continue to queue mesages to the "stuck" association until the 
>>> queues fill up and/or overflow.
>>>
>>> Using an end-to-end health check mechanism (such as M3UA or SUA 
>>> BEATs) solves this problem pretty nicely (similar to the way 
>>> periodic SLTMs do in MTP3).  However, I suspect many M3UA/SUA 
>>> implementors may not implement or may not turn on (by default) BEATs 
>>> under the (false, due to the reasons listed above) pretense that 
>>> SCTP heartbeats are sufficient to ensure the viability of the 
>>> association.
>>>
>>> What to do?  Should the RFCs recommend (or even require) using 
>>> BEATs, even when run over SCTP?  (This is just a recommendation 
>>> change for the RFCs but is a complete reversal for ETSI--but I guess 
>>> that's not this list's problem.)
>>>
>>> Regards,
>>> -Jeff
>>>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Oct 2005 20:12:50 +0200

Jeff,

if you think that it is good to send BEAT messages you can do it. The 
RFC 3332 and
the ETSI spec REQUIRE the sending of a BEAT-ACK on reception of a BEAT.

So you are free to send them...

Best regards
Michael

On Oct 3, 2005, at 16:29 Uhr, Jeff Morriss wrote:

>>>>> However, SCTP (in particular, the I-G) allows the association to 
>>>>> get "stuck" such that it will pass no data: a receiver is allowed 
>>>>> to hold its window closed "for an indefinite time" (new text for 
>>>>> section 6.1 A).
>>>>
>>>>
>>> RFC 2960 doesn't specifically mention that the receiver is allowed 
>>> to hold it closed indefinitely while the I-G specifically mentions 
>>> it:
>>>
>>> ~~
>>> Yes, that's exactly the point.  If the BEATs fail that means the 
>>> assoc isn't carrying traffic.
>>>
>>>
>>>>> indefinately.
>>> "the system" should be able to detect the problem, reset, and keep 
>>> going (or at least try real hard to do so).
> No amount of testing and validation will uncover every single bug in 
> the system.  (And I do hope the above was a typo and you do you know 
> the difference between a bug and a design problem.)
>
>>>>> This leads to very serious traffic loss since M3UA will continue 
>>>>> to queue mesages to the "stuck" association until the queues fill 
>>>>> up and/or overflow.
>>>>
>>>>
>>> True, but what if the window being closed is due to a bug in the 
>>> peer and that peer won't ever recover until the assoc is reset 
>>> (read: is torn down and gets a fresh start on life)?
>>>>> periodic SLTMs do in MTP3).
>>>>
>>>>
>>> We're talking about a "stuck" assoc.  Those BEATs/SLTMs will _never_ 
>>> be responded to; in MTP3 2 such failures will cause the link to be 
>>> failed (T1.111.7 section 2.2).
> So that there are never, ever, sustained call failures?  Or at least 
> not avoidable ones?
>
>>> Except that the bug has now caused the peer to be permanently 
>>> congested (unless there's a failure due to excessive congestion--I 
>>> haven't checked).
> A timer guarding the congestion would solve all that, so that's 
> probably the way to go.
>
>>>>> change for the RFCs but is a complete reversal for ETSI--but I 
>>>>> guess that's not this list's problem.)
>>>>
>>>>
>>> I suppose that the peer being marked as congested will certainly 
>>> raise alarms throughout the network (which would at least make the 
>>> problem visible to everybody, not just the adjacent node) but in my 
>>> experience, there are a fair number of bugs which can be 
>>> automatically (no manual intervention--which may not arrive for 
>>> several hours) fixed by simply resetting the troubled thing.  Unless 
>>> there is an "excessive congestion" clause, this won't help.
> Hmmm, I disagree.  Reading the specs would lead one to believe that 
> one is reasonably safe in letting SCTP manage the viability of the 
> assocs (and M3UA's ability to send data on them).  This could lead 
> implementors to ignore this potential problem until they run into it.
>

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 03 Oct 2005 19:03:50 -0400

Hi Brian,

> Splitting hairs.  Either the SCTP implementation of appplication are

I would if I could...  But I don't own it (so I can't).

> implementation might SIB at some point, but that would be implementation

My memory (which may have faded) tells me that, as a sender with 
messages queued to the peer, if the peer does not give me a new 
acknowledgment (so I can take something off my RTB) within T7, I kill 
the link.

> SLTM is not used in this way.

I've seen it used that way (in real, but possibly not very healthy, 
networks).

> your application sticky bug problem.

I hope not...  (And I hope the peer in this particular case will have 
the problem solved real soon now.)

> cross connect and loopback problems.

I don't think I ever said it was meant to check the health of MTP3.  But 
to really verify/prove that MTP2 is working (and your connections to it 
are also working), you need to pass some data over/through it.  SLTMs do 
that (assuming they are handled up at MTP3).

> significant level of traffic would otherwise be applied to the link.

Yes, that's what alignment SLTMs are for.  Once the link is aligned, 
that use is basically gone.

> below that, the BEAT will also be delayed.

In fact I don't have a particular attachment to BEATs; it just seemed 
like a convenient method for checking if the assoc is _actually_ 
carrying traffic.

> correct implementation sees as an unnecessary failure (of the

Sounds like a good use for a timer with a range of recommended values.  :-)

Regards,
-Jeff

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 03 Oct 2005 19:06:31 -0400

Hi Michael,

> This means that you have a broken SCTP implementation. What does is mean 
> in particular:

Yes, we know the implementation is broken--but I can't help/fix that
(it's not ours).

In this case it continues to SACK (with a_rwnd set to some reasonable
number) but it does not increment the TSN that it is SACKing.  We
(quickly) fill what we see as the peer's actual window (advertised minus
what we've got in the queue for it) and sit there and probe all day.

I'd love it if it would just stop SACKing (because then our SCTP would
tear the assoc down).

Regards,
-Jeff

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Oct 2005 19:57:45 -0600

Jeff,

Jeff Morriss wrote:                                                                    (Mon, 03 Oct 2005 19:03:50)
> that (assuming they are handled up at MTP3).

The ability of the link to pass data is performed during Proving with SIN
and SIE.

> Sounds like a good use for a timer with a range of recommended values.  :-)

There is not "one fits all" recommended range because the underlying networks
over which M3UA runs vary much more widely than that of SS7.

The type of document for such a discussion in IETF is an "Applicability
Statement".  I invite you to draft one for M3UA: I will look forward to
commenting on it.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 04:02:53 -0600

Jeff,

Jeff Morriss wrote:                                                                   (Mon, 03 Oct 2005 19:06:31)
> I'd love it if it would just stop SACKing (because then our SCTP would

If you are implementing Core Network under TS 29.202, read Annex A that
says that HEARTBEAT is Mandatory.  Send a HEARTBEAT if you think it will
help.

--brian

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

---

From: Jeff Morriss <[email-masked]>
Date: Tue, 04 Oct 2005 08:40:03 -0400

Hi Brian,

> The ability of the link to pass data is performed during Proving with SIN

True, that aligns MTP2.  But in most of the SS7 implementations I've 
seen, MTP2 is performed on a line card or similar.  In order for the 
rest of the stack to actually use the SS7 link, there has to be some 
amount of "plumbing" established between the card and MTP3.  That's 
usually pretty easy and reliable but, as with all things, there's the 
potential for something to go wrong.  Such problems could leave MTP2 
aligned but MTP3 unable to use it.

Regards,
-Jeff

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Oct 2005 11:27:42 -0600

Jeff,

Jeff Morriss wrote:                                                                   (Tue, 04 Oct 2005 08:40:03)
> aligned but MTP3 unable to use it.

That would be a Local Processor Outage condition that would send SIPO.

--brian

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