Subject: [Sigtran] SIGTRAN Plugtest Day 3

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 19 Apr 2007 10:16:21 +0400

Greetings from Moscow! Here is the wrap-up report for Day 3 of the SIGTRAN
Plugtest.

Protocols tested:
M2PA - 5 implementations
M3UA - 6 implementations
M2UA - 2 implementations
SUA  - 2 implementations

There was one issue raised at the Day 3 wrap-up:

Some ASP implementations are not resending the ASP-Active msg, after not
receiving the ASP-Active-Ack from the SGP. This behaviour is of course
allowed by RFC 4666. The RFC states that:

<snip>
"If the ASP does not receive a response to an ASP Active message
within T(ack), the ASP MAY restart T(ack) and resend ASP Active
messages until it receives an ASP Active Ack message."
<snip>

However the consensus within the group is that such behaviour is not very
logical, and that it would be helpful if the "MAY"
in the text above would be replaced with "SHOULD".

Barry Nagelberg

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 01:58:43 -0600

Barry,

What problem results from not resending ASP Active?

--brian

Barry Nagelberg wrote:                    (Thu, 19 Apr 2007 10:16:21)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 19 Apr 2007 12:06:44 +0400

Brian,

The problem is that there must be a person present at a terminal somewhere
to push a button to resend the ASP-Active. I doubt that many carriers would
be happy about this.

Barry

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, April 19, 2007 11:59 AM
To: Barry Nagelberg
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Barry,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 02:20:43 -0600

Barry,

You misunderstood the question, I think.  Let me rephrase:

Why would it be necessary to resend ASP Active?  (The first one surely
arrived: SCTP being a reliable transport.)

--brian

Barry Nagelberg wrote:                                  (Thu, 19 Apr 2007 12:06:44)

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 19 Apr 2007 12:34:41 +0400

Brian,

If the SGP doesn't send ASP-Active-Ack. This could happen for a thousand
different reasons: misconfiguration, power hit, etc.

Barry

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, April 19, 2007 12:21 PM
To: Barry Nagelberg
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Barry,

--brian

Barry Nagelberg wrote:                                  (Thu, 19 Apr 2007
12:06:44)

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

---

From: "Erickson, Mark" <[email-masked]>
Date: Thu, 19 Apr 2007 03:43:11 -0500

Brian:

It's not a question of SCTP.  What if the first one is refused by the SG
for some reason - why shouldn't the ASP keep resending to try to bring
the ASP into service?

If the SGP has been configured such that it refuses the ASP-ACTIVE
request, if an operator changes the configuration as the SGP to permit
the SGP to accept the request and bring the ASP active, there is no way
to signal the ASP what has occurred at the SG, and both sides should not
have to rely on some mechanism that forces the ASP to return to a DOWN
state (such as restarting the association) to cause the process to be
restarted automatically or require some manual intervention at the ASP
end.

Mark

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 4:21 AM
To: Barry Nagelberg
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Barry,

--brian

Barry Nagelberg wrote:                                  (Thu, 19 Apr
2007 12:06:44)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 05:35:47 -0600

Erickson,,

Erickson, Mark wrote:                                                            (Thu, 19 Apr 2007 03:43:11)
> for some reason - why shouldn't the ASP keep resending to try to bring

Well, if the first one is refused, then an Error message MUST be
returned identifying the reason (e.g. Management Blocking).  If the ASP
considers this refusal to be of a transient nature, it is welcome to
issue another ASP Active attempt at any time (even immediately).  If the
ASP would like to simply ignore such ERROR messages and fall back on a
Tack timer, it is also welcome to do so.  However, I do not think that
it can be recommended that the timer be used when the Error message will
do and so the SHOULD keyword does not apply.

Tack was intended for the case where _no_ reply comes from the SGP
within the timer.  In this case either there is a significant delay on
the association (longer than Tack RTT) or the SGP does not comply with
the ASP Active procedures.  Both indicate a more serious problem and
that is why we said that Layer Management could be informed instead of
retransmitting another ASP Active into a black hole.

I don't think that recommending retransmission solves issues with SGP
that refuse to send Error messages or ASPs that refuse to process them.

--brian

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

---

From: "Erickson, Mark" <[email-masked]>
Date: Thu, 19 Apr 2007 07:01:08 -0500

Brian:

I'll agree that the SG must answer to the ACTIVE request - that's not my
point.  A failure to do would use the Tack timer to force the ASP to
retry.

However, if an error is sent back (as you indicate, Management Blocking)
- which could indicate a configuration issue, and the configuration
issue is resolved, there is no automatic recovery mechanism other than
to either rely on the Tack timer or force the ASP to the DOWN state BY
the SG (if it could!!) - and the only way I can see the latter happening
is to force the association down, which is just wrong (consider if the
association is a member of another AS that is in a traffic handling
state).

MARK

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 7:36 AM
To: Erickson, Mark
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Erickson,,

Erickson, Mark wrote:
(Thu, 19 Apr 2007 03:43:11)

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 06:39:51 -0600

Mark,

Recovery from a configuration error is an operational issue and not a
protocol issue.  The protocol provides all of the protocol elements
necessary to determine the cause of the error.  Whether the ASP attempts
recover automatically or not is not only an operational consideration,
but one that is local to the ASP.  In doing so, the ASP either makes
assumptions about provisioned information or is privy to provisioned
information using mechanisms outside the protocol.  Retransmitting after
after Tack can be inappropriate for some operational environments and
certainly cannot be made as a blanket recommendation in a protocol
specification.  From a protocol perspective, it is sufficient to say that
the SGP MUST respond.  What the ASP does as a result of a refusal is a
local operational consideration.  Nevertheless, two suggestions (MAY)
appear in RFC 4666 and other UA RFCs: retransmit, inform management.

Should people consider this when designing their APS?  Yes, indeed.  Does
it have a place as a full recommendation in a protocol specification?  No.

--brian

Erickson, Mark wrote:                         (Thu, 19 Apr 2007 07:01:08)

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

---

From: "Erickson, Mark" <[email-masked]>
Date: Thu, 19 Apr 2007 08:04:01 -0500

Brian:

A robust protocol's description must not only provide the elements to
for each side to signal what happened, but then must also provide
recovery mechanisms for faults.  Granted this is an operational issue,
but doesn't a protocol also provide procedures for other 'operational'
issues (congestion for one)?

The ASP, in this case, is not making ANY assumptions - it knows the far
end is in the ASP-INACTIVE state, and simply probing to see if the far
end is ready to change state as it has been commanded.  The point is
requiring local management to intervene.  What does this mean - the M3UA
user now has to implement a retry mechanism for automatic recovery?

Treating issues like this one in such a fashion only leads interop
issues (due to differences in interpretation of the protocol
description) which detracts from the robustness of the protocol (which,
BTW, is why we're here in the first place).

Mark

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 8:40 AM
To: Erickson, Mark
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Mark,

specification.  From a protocol perspective, it is sufficient to say
that

Should people consider this when designing their APS?  Yes, indeed.
Does
it have a place as a full recommendation in a protocol specification?
No.

--brian

Erickson, Mark wrote:                         (Thu, 19 Apr 2007
07:01:08)
> > It's not a question of SCTP.  What if the first one is refused by
the
> SG

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 08:31:32 -0600

Erickson,,

Erickson, Mark wrote:                                                            (Thu, 19 Apr 2007 08:04:01)
> issues (congestion for one)?

IUT ones yes, IETF ones no.

> user now has to implement a retry mechanism for automatic recovery?

This is no different than, say, SCTP where if the connecting peer receives
and ABORT, the application is issued an error and must reattempt itself.
It does not matter for SCTP whether it is a configuration error, managment
blocking (firewall), the application is given an error and the connection
attempt is abadonned.

Informing the application of a certain error as soon as possible is good
design.  If M3UA automatically retransmits automatically, the first thing a
application is going to want to do is shut it off.

> BTW, is why we're here in the first place).

There is no interoperability issue: perhaps an operational in some
environments with some specific implementations.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 08:32:58 -0600

Mark,

Brian F. G. Bidulock wrote:                                     (Thu, 19 Apr 2007 08:31:32)
> IUT ones yes, IETF ones no.
  ^^^  ITU

--brian

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

---

From: "Erickson, Mark" <[email-masked]>
Date: Fri, 20 Apr 2007 01:10:23 -0500

Brian:

See below

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 10:32 AM
To: Erickson, Mark
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Erickson,,

Erickson, Mark wrote:
(Thu, 19 Apr 2007 08:04:01)

<MAE> What???

> user now has to implement a retry mechanism for automatic recovery?

This is no different than, say, SCTP where if the connecting peer
receives
and ABORT, the application is issued an error and must reattempt itself.
It does not matter for SCTP whether it is a configuration error,
managment
blocking (firewall), the application is given an error and the
connection
attempt is abadonned.

Informing the application of a certain error as soon as possible is good
design.  If M3UA automatically retransmits automatically, the first
thing a
application is going to want to do is shut it off.

<MAE> 'Operational' issues expose weak/vague areas in a protocol that
can and should be strengthened.

--brian

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

---

From: "Newman, Catherine J" <[email-masked]>
Date: Fri, 20 Apr 2007 06:41:38 -0400

I agree with Mark - the protocol should require the actions for
automatic recovery. This is what carriers will expect.

Cathy Newman
Project Manager - SS7 Testing and Analysis

-----Original Message-----
From: Erickson, Mark [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 2:10 AM
To: [email-masked]
Cc: SIGTRAN Mailing List
Subject: RE: [Sigtran] SIGTRAN Plugtest Day 3

Brian:

See below

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 10:32 AM
To: Erickson, Mark
Cc: SIGTRAN Mailing List
Subject: Re: [Sigtran] SIGTRAN Plugtest Day 3

Erickson,,

Erickson, Mark wrote:

<MAE> What???

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Apr 2007 06:15:14 -0600

Cathy,

And they are welcome to specify it in their operational (generic ;)
requirements.

ETSI has already specified a number of restrictions for use in GSM/3GPP
networks.  Perhaps ANSI (or Telcordia) will do the same.

We could place in in Appendix A, with other operation considerations,
but we will not use the keyword SHOULD there, just MAY: as it is
already.

--brian

Newman, Catherine J wrote:              (Fri, 20 Apr 2007 06:41:38)

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