Subject: [Sigtran] M3UA plugtest - Day 3 summary

From: Ken Morneault <[email-masked]>
Date: Thu, 28 Feb 2002 04:44:54 -0500

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2002 12:05:25 -0600

Ken,

Please see comments below...

Ken Morneault wrote:                                          (Thu, 28 Feb 2002 04:44:54)
> sent if the SS7 destination is congested.  

The spec doesn't say this.  It says that the SCON MUST be
sent when an SS7 destination is congested and the SG maintains
congestion states.  If the destination is not congested
(or unknown) it can do what it wants.  An implementation
can always send SCON(0) if it wants.

> bytes of the subparameters (even padding bytes in subparameters)

I concur.

> dynamic registration not supported.

It seems a minor thing at this point.

> Parameter because a congestion level is not available.

We went to great lengths in the WG to keep protocol dependencies
out of the M3UA layer.  How is an M3UA implementation to know
when a Cong Ind must by sytactically included in the message
when it does not know what protocol variant it is transporting?

If Cong Ind become and optional parameter, when it is missing
it need to describe ASNI Level 0 for ANSI so that the imp does
not need to know the protocol variant when syntax checking the
received message.  The draft chose to go the other way: make
the Cong Ind parameter mandatory and set it to 0 for ITU, rather
than make it optional and have it indicate level 0 when missing.

I see no need to reverse this now.  Perhaps the Imp Guide could
mention that an implementation might want to treat a missing
Cong Ind as Cong Ind = 0 rather than rejecting the message, but
Cong Ind is a mandatory parameter and must be sent in the
message.

> In the case of DATA, the reference would be MTP

We changed this to "as appropriate" because it is the NIF that
determines when SCON is sent in reponse to DATA or DAUD.
The NIF is not specified in M3UA.  In the case of DAUD, the
SG NIF might not (or might) maintain congestion states.
The same is true for DATA.  An MTP reference would be of little
use because the handling of congestion indication between the
MTP-User and MTP are rather different depending on the variant.
Also, there was much dicussion about sending SCON in repsonse
to SCTP congestion as well as nodal congestion.  In short
SCON is necessary for interworking with the SS7 network and
the M3UA draft does not specify that interworking.

That's what "as approapriate" means.

> "semi-mandatory" RC have priority over NA?

I mentioned the possibiltiy of this conflict during the
RC/NA dicussions and Lydon an some others were of the
belief that such a conflict couldn't occur. :)

RC should not take priority over NA in this case.  The
message is simply invalid.

--brian

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 28 Feb 2002 12:31:32 -0600

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

1)  Audit (DAUD)

 Examples:

         ASP                                    SG

         ASP                                    SG

         ASP                                    SG

         ASP                                    SG

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2002 13:03:53 -0600

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? ;)

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.

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.

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)

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 28 Feb 2002 14:48:42 -0600

...Inside the text...
Thanks.

Jacques Rajchgod
MCI Worldcom

-----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,

------------------------

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.
-----------------------

----------------------

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.
----------------------

----------------------

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.
----------------------

--brian

Jacques Rajchgod wrote:                                   (Thu, 28 Feb 2002
12:31:32)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Feb 2002 16:24:00 -0600

Jacques,

Jacques Rajchgod wrote:                                   (Thu, 28 Feb 2002 14:48:42)

<snip>

Jacques, this is not the case.  The error code is "Unsupported Message Type"
and in the Diagnostic is the message type RKMM REG REQ.  What the imp
is saying is "dynamic registration is not supported because I do not even
recognize the message type".  This is forward compatible.  It is an ERROR
because the request could not be satisfied, to cancel a possible ack timer.

Registration is an OPTIONAL procedure.  Providing an explicit error code
for when it is not supported would make at lease part of the procedure
non-optional.  (Implementations would be forced to recognize RKMM messages.)

If an implementation recognizes RKMM messages, it might as well respond
with a REG RSP with an error: unsupported routing key.  But that would defeat
the purpose of this procedure being OPTIONAL.

--brian

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