Subject: RE: [Sigtran] RE: Dynamic Registration not supported - Day 3 summary

From: [email-masked]
Date: Thu, 28 Feb 2002 15:54:21 -0500

Thanks Jacques, for your excellent points. I and several others have been 
requesting, in vain, the addition of more robust and descriptive error 
messaging ever since the first M3UA bakeoff at Madrid in May 2001.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

Jacques Rajchgod <[email-masked]>
Sent by: [email-masked]
02/28/02 03:48 PM

        To:     [email-masked]
        cc:     Ken Morneault <[email-masked]>, [email-masked]
        Subject:        RE: [Sigtran] RE: Dynamic Registration not supported - Day 3 summary

...Inside the text...
Thanks.

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Thursday, February 28, 2002 1:04 PM
To: Jacques Rajchgod
Cc: Ken Morneault; [email-masked]
Subject: Re: [Sigtran] RE: Dynamic Registration not supported - Day 3
summary

Jacques,

Are you saying that you intend to hook up boxes that don't support
dynamic registration with those that require dynamic registration
in the field? ;)
------------------------

J.R:
In the real world, we will have various implementations interoping, and it
is quite likely that some will not operate like others. Reality is, that 
we
need good "technical cops" out there to control ops as it is quite likely
that we will see - as Ken just saw in Day-3 - problems that are "not
supposed to exist..." like you are implying below.
The "technical cops" are the accurate error messages that are supposed to
tell offenders about their offenses.
-----------------------

This is a configuration detail.  A properly configured system would
never send this new error code.  As such it is worthless except in
the lab.
----------------------

J.R:
My experience has shown differently. What one sees in a lab is quite 
likely
to be what will be seen - to various degrees - in production. Human 
nature.
It is humans who design products. To be effective, thus, the good 
"technical
cops" need be sharp so offenders can readily understand what it is they 
are
being repudiated about. This must take place in the easiest possible way.
See below...next.
----------------------

Error messages now include the offending message in the diagnostic.
The sender of the message should be fully capable of decoding their
own registration message which appears in the diagnostic.  That is:
the ERR("Unsupported Message Type") also includes in the diagnostic
the offending RKMM REG REQ message.
----------------------

J.R:
A Rejected REG_REQ can be rejected for more than one reason (Inval,
not_config'ed...). Telling a machine "Go and look in your Diag byte at 
your
REG_MSSG and draw your own conclusions as to why you got rejected" is far 
a
cry from "You got rejected because your peer does not work like you - not
because you are necessarily wrong - he doesn't understand you". Protocols
used in the industry in the last three decades have used the error message
"Unsupported Function" to highlight requests that could not be fulfilled.
The distinction had always been made between something that could not be
fulfilled and something that could be fulfilled but was in ERROR. We need
the same approach to UA  times, whence my suggestion for appropriate and
fitting (<--- note the descriptor "fitting") ERROR messages.
----------------------

This is a fully general mechanism which is forward compatible.  There
is no need for a special "Dynamic registration not supported".  The
current error message contains sufficient information.

--brian

Jacques Rajchgod wrote:                                   (Thu, 28 Feb 
2002
12:31:32)
> Dead on! Re:
> -------------------------------------------------------------
> 3)  Dynamic Registration not supported
>
> RIght now the text indicates the SG should return Error (unsupported
> message type).  Prefer to have a specific error code indicating
> dynamic registration not supported.
> ------------------------------------------------------------
>
> This has cost us many hours of unwarranted tbshting (Troubleshooting) by
> leading Engineers astray:
> A message saying "UNSUPPORTED MESSAGE TYPE" is dramatically different 
from
> one saying "I CANNOT DO FUNCTION "x".
> The two are totally different by virtue of meaning different things:
> "UNSUPPORTED MESSAGE TYPE" - means: "You have sent me an erroneous
message".
> "I CANNOT DO FUNCTION "x" - means: Your message might be OK but I cannot
> check it because I am not built for that!"
>
> The suggested def of "Dynamic Registration not supported" is exactly 
what
is
> needed.
> Correct definitions of error messages are critical to production
> environments! We need them sharp...
>
>
> Jacques Rajchgod
> MCI Worldcom
> Next Generation System Evaluation
> Tel: [972] 729-7180
> E-mail: [email-masked]
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ken Morneault
> Sent: Thursday, February 28, 2002 3:45 AM
> To: [email-masked]
> Subject: [Sigtran] M3UA plugtest - Day 3 summary
>
>
>
>
> Here are the issues raised on Day 3 of the plugtest:
>
>
> 1)  Audit (DAUD)
>
> There is a weak point in the current Audit procedure (Section
> 4.5.3) in regards to congestion state.  The SCON is only
> sent if the SS7 destination is congested.
>
> The SG maintains the congested state:  Congested/-
> Uncongested/Unknown (ITU International only) and the
> available state: DRST/DUNA/DAVA state.  When the
> Audit occurs, the SG should send both pieces of
> state information.
>
>  Examples:
>
>      SG state:  Uncongested/Available
>
>          ASP                                    SG
>                  --------- DAUD --------------->
>                  <------- SCON (0) -----------
>                  <------- DAVA-----------------
>
>      SG state:  Congested (2) /Available
>
>          ASP                                    SG
>                  --------- DAUD --------------->
>                  <------- SCON (2) -----------
>                  <------- DAVA-----------------
>
>      SG state:  Unknown (ITU International network) /Available
>
>          ASP                                    SG
>                  --------- DAUD --------------->
>                  <------- DAVA-----------------
>
>      SG state:  Uncongested/Unvailable
>
>          ASP                                    SG
>                  --------- DAUD --------------->
>                  <------- DUNA-----------------
>
>
> 2)  Length of Routing Key Parameter in Registration Message
>
> The length of the Routing Key parameter should include all
> bytes of the subparameters (even padding bytes in subparameters)
> that it contains.
>
> 3)  Dynamic Registration not supported
>
> RIght now the text indicates the SG should return Error (unsupported
> message type).  Prefer to have a specific error code indicating
> dynamic registration not supported.
>
> 4)  SCON for International ITU
>
> Clarifications among the participants that for International
> ITU the SCON will be sent without a Congestion Indication
> Parameter because a congestion level is not available.
>
> 5)  Statement in SCON text should be clarified
>
> Section 3.4.4 states the SG can send SCON in response
> to a DATA or DAUD "as appropriate".  There should be
> a reference to what "as appropriate" means.  In the
> case of DAUD, the reference would be Section 4.5.3.
> In the case of DATA, the reference would be MTP
> specs.
>
> 6)  RC and NA in DATA msg can be misleading.
>
> This issue was brought up because of a scenario with
> no NA defined.  One implementation was sending
> DATA messages with RC and NA (even though
> NA was undefined).  The other implementation
> was throwing away the DATA messages because
> NA was invalid.  However, the rest of the DATA
> message including the RC was valid.  Should
> "semi-mandatory" RC have priority over NA?
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

_______________________________________________
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, 28 Feb 2002 16:31:18 -0600

Barry,

The issue that came out of Madrid was correlation of error messages, not
overloading the error code.  This issue was resolved by adding the offending
message into the Diagnostic in the Error message so that the receiver of
the Error could use it to correlate the Error response with the sent message.
Correlation is necessary to cancel any timers or pending actions in the
implemenation that would otherwise continue to wait for a response.  For
management purposes the generic error code and the entire offending message
are quite suitable for diagnostics, paritcularly in this case.

In Madrid it was not possible to correlate ERR with any message sent and if
multiple ASPAC Requests were being performed, for example, an ERR could not
be correlated to the ASPAC requests (an imp could not tell which ASPAC request
failed).  Adding the message to the Diagnostic solved this.

The general feeling on the list and the concensus that was reached when
Ken redid the error handling was that a proliferation of error codes should
be avoided.  There is no reason to change that stance now.  This situation
with REG REQ is just the failure of the imp receiving the error to use the
information that it has at its disposal in the Diagnostic portion of the
message.  There is no defense against lazy implementation.

--brian

[email-masked] wrote:                (Thu, 28 Feb 2002 15:54:21)

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