Subject: M3UA v9: Diagnostic Information

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Oct 2001 15:28:08 -0500

Section 3.8.1 says:

   identification of the error condition.  In the case of an Invalid 
   Network Appearance, Traffic Handling Mode, Routing Context or 
   Parameter Value, the Diagnostic information parameter MUST be added 
   and include the offending parameter.  In the case of Destination 
   Status Unknown, the Diagnostic information SHOULD include the Point 
   Code in the original DAUD request.

There is certainly no reason for a MUST here.  In most implementations
the diagnostic information will be ignored during normal operation.

Change MUST to MAY.

There is no reason for the SHOULD either.  Implementations sending DAUD
must remember for which point code it was sent and from the discussion on
DAUD there is little point to auditing specific point codes periodically
or otherwise.  Only restart (basically DAUD(*)) are useful.

Change SHOULD to MAY.

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 16 Oct 2001 19:32:07 +0200

Hi Brian, 

See comments below...

Cheers // Javier.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 10:28 PM
> To: sigtran
> Subject: M3UA v9: Diagnostic Information
> 
> 
> Section 3.8.1 says:
> 

I can happen in your implementation, but maybe the others take actions depending on that. From my point of view is important enough to keep the MUST. 

> or otherwise.  Only restart (basically DAUD(*)) are useful.

Same thing. If an implementation decides to use DAUD with a single SPC, and it sends two different DAUDs with two different SPCs and receives only an error, it would like to know which one had the problem. Therefore the remote implementation should give this information back. I think we should keep the SHOULD here as well...

> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 16 Oct 2001 13:48:20 -0400

I agree with Javier on both of these issues.

Ken

At 07:32 PM 10/16/01 +0200, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 13:02:55 -0500

Javier,

Please see comments below...

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 16 Oct 2001 19:32:07)
> >    Network Appearance, Traffic Handling Mode, Routing Context or Parameter
> >    Value, the Diagnostic information parameter MUST be added and include
> >    the offending parameter.  In the case of Destination Status Unknown,
> >    the Diagnostic information SHOULD include the Point Code in the
> >    original DAUD request.
> > 
> I can happen in your implementation, but maybe the others take actions
> depending on that. From my point of view is important enough to keep the
> MUST. 

No actions have been described in the draft and the "MUST" is unjustified
in terms of "making" an implemetnation send it when there is not even
a mention of its use.  Further the coding of the invalid information into
the diagnostic is unspecified.  Does the coding into the diagnostic
include the TLV? What if the parmaeter was too short?  What if it was
possibly incorrectly padded?  What if the parameter was missing from the
message when mandatory?  What is included then?

If you want to keep this "MUST" you will need to describe both how
to code it and make recommendations on just what actions you expect an
implementation to take based on these.

> Same thing. If an implementation decides to use DAUD with a single SPC, and
> it sends two different DAUDs with two different SPCs and receives only an
> error, it would like to know which one had the problem. Therefore the remote
> implementation should give this information back. I think we should keep the
> SHOULD here as well...

You will then have to specify the coding in the diagnostic.  The PC itself
in isolation of RC or NA is completely useless in configurations where RC
or NA are required to determine the point code numbering space to which the
SPC applies.  It is insufficient to ever just identify a point code as just
an SPC.  So it is effectively useless here in mutliple network configurations.
Where there are multiple RCs, there may be different responses to different
querying MTP-Users on a DAUD.  One might be in error (refused) for one RC
but answered for another.  The error message must be qualitfied with an RC
that applies to the Error Message if you want to include it.   Then there
needs to be an RC that identifies the RC to which the DAUD APC applies to.
Where are these RCs to be placed in the ERR message?

Adding these in this fashion is pointless.  Either drop SHOULD to MAY or
clean up the idneitification of DAUD information.  The ERR information
must contain all the information that the original DAUD did (why not include
the entire message).  As there are different error messages that can be sent
for the same error condition (error conditions are not mutually exclusive)
one implementation may send one error when another sends another.  Neither
will have sufficient information to determine the original DAUD.

If you want to place these requirements on implemetnations, please describe
them far better.  You will need text and ERR message parameter changes to
effect your intentions here... 

Or, you could simply change "MUST" to "MAY" and "SHOULD" to "MAY".  I didn't
see anyone jump in a say that the implementations simply needed this
diagnostic information or it couldn't interoperate...

--brian

> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:38:34 -0500

Ken,

Then perhaps you can explain how the ASP is going to interpret
the point code without RC or NA to provide reference to the
numbering space.  Perhaps you can also describe how you see
the ASP correlating which AS generated the DAUD from the ERR
message which doesn't appear to contain the RC of the AS.

--brian

Ken Morneault wrote:                                          (Tue, 16 Oct 2001 13:48:20)

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 16 Oct 2001 21:12:56 -0400

Brian,

I don't intend to use the information internal to the ASP.   The
invalid NA, invalid RC, unknown PC and invalid Traffic Mode
indicate that something has been mis-configured.  This
information could be passed to an operator in an alarm
or logged so that the problem could be quickly resolved.

I agree (and have complained in the past) that there needs
to be more discussion on coding these parameters.  Further,
I agree a PC would need NA or RC from the offending 
DAUD if NA or RC was present.

Regards,

Ken

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 20:39:02 -0500

Ken,

Ken Morneault wrote:                (Tue, 16 Oct 2001 21:12:56)
> DAUD if NA or RC was present.

If it has MUST, lets get the diagnostic coding complete and
ensure that all the necessary information is present in the
diagnostic.

Better still, why not include the offending message as it was
recieved?  (i.e., the entire DAUD complete with message type).
This would not be much trouble.

Further there is the question as to what PC is included in the
diagnostic if the ASP does DAUD(*) or does a DAUD(cluster)
on which it is only allowed to access information for several
members in the cluster.  The ERR message would have to contain
a list of all the other PCs in the cluster to which the ASP
was being denied access (particularly if you leave it at "MUST").
This means that there might be a need to represent almost
2^24 point codes in the diagnostic!

First off, the SHOULD for PC needs to be relaxed to permit the
SGP to not include all the other members of the cluster or
entire network.  If it is not relaxed all the way to MAY, then
the format of the diagnostic, the necessary parameters included
and the point codes which will be included (certainly not 2^24!).

If the MUST is not relaxed on RC and others, the format of the
potentially mangled parameter (e.g., too short, not padded) in
the diagnostic must be specified and the parameters necessary
to correlate the error with the offending message must be
included as well.

The draft should certainly not say that an implementation "MUST"
or "SHOULD" do something, but then leave how that is to be done
unspecified.  "MUST" and "SHOULD" need to be used to promote
interoperability, not to require vague non-interoperable procedures.

We need to either specify how it is to be done, or remove the
requirement ("MUST" and "SHOULD" diction).

Since you are such an advocate of the uses of the diagnostic,
perhaps you would propose a specification of its coding in support
of maintianing the requirement to provide it?

I eagerly await your proposed text. ;)

--brian

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 16 Oct 2001 22:31:04 -0400

I'll send a proposal out in a few days.

Ken

---

---

From: Ken Morneault <[email-masked]>
Date: Thu, 18 Oct 2001 21:25:34 -0400

A proposal for changes to the error message is below.  These
changes better explain how some offending parameters would
be included in the error message in order to feedback 
important diagnostic information the the sender.  This
diagnostic information is intended to help enable 
resolution of the error (most likely a provisioning error).

This proposal has some open discussion points:

1)  is it important to be able to correlate the error with
the offending message?  if so, then the Diagnostic Information
MUST (instead of MAY) contain the entire message in error.
This would be in addition to placing the offending 
parameter, when appropriate, in the Error message.  

2)  It seems better to handle Brian's concern of DAUD(*) 
and DAUD(cluster) in Section 3.4.3.

When the SG receives a DAUD with a mask that indicates some bits of the point code are wildcarded, the SG shall respond with the status of the point codes authorized to be seen by the sender.  The SG will not send an Error message for the other point codes. 

3)  The only parameters that could be included would be:  Routing
Context, Affected Point Code, and Network Appearance.  Traffic Mode
and Invalid Parameter were removed.  There does not seem to be a 
need for Traffic Mode type since ASP would know which traffic mode 
type it supports.   Invalid Parameter is too general.

I look forward to comments.

Ken

3.8.1  Error

The Error message is used to notify a peer of an error event associated 
with an incoming message.  For example, the message type might be 
unexpected given the current state, or a parameter value might be 
invalid.  

The Error message contains the following parameters:

      Error Code                 Mandatory
      Routing Context            Mandatory*
      Network Appearance         Mandatory*
      Affected Point Code        Mandatory*
      Diagnostic Information     Optional

(*) only mandatory for specific error codes

The format for the Error message is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x000c         |          Length = 8           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Error Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                       Routing Context                         / 
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Tag = 0x0012          |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Mask     |                 Affected PC 1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                              ...                              /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Mask     |                 Affected PC n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0200          |         Length = 8            |   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    |                     Network Appearance                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Tag = 0x0007         |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                                                               \
    /                     Diagnostic Information                    /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error Code: 32-bits (unsigned integer)

    The Error Code parameter indicates the reason for the Error Message. 
    The Error parameter value can be one of the following values:

      0x01      Invalid Version 
      0x02      Not Used in M3UA
      0x03      Unsupported Message Class
      0x04      Unsupported Message Type 
      0x05      Unsupported Traffic Handling Mode 
      0x06      Unexpected Message
      0x07      Protocol Error
      0x08      Not used in M3UA
      0x09      Invalid Stream Identifier
      0x0a      Not used in M3UA
      0x0b      Not used in M3UA
      0x0c      Not used in M3UA
      0x0d      Refused - Management Blocking
      0x0e      ASP Identifier Required
      0x0f      Invalid ASP Identifier
      0x10      Invalid Routing Context
      0x11      Invalid Parameter Value
      0x12      Parameter Field Error
      0x13      Unexpected Parameter
      0x14      Destination Status Unknown
      0x15      Invalid Network Appearance          

The "Invalid Version" error is sent if a message was received with an 
invalid or unsupported version.  The Error message contains the 
supported version in the Common header.  The Error message could 
optionally provide the supported version in the Diagnostic Information 
area.

The "Invalid Network Appearance" error is sent by a SGP if an ASP sends 
a message with an invalid (unconfigured) Network Appearance value.  For
this error, the invalid Network Appearance parameter MUST be included.

The "Unsupported Message Class" error is sent if a message with an 
unexpected or unsupported Message Class is received.

The "Unsupported Message Type" error is sent if a message with an 
unexpected or unsupported Message Type is received.

The "Unsupported Traffic Handling Mode" error is sent by a SGP 
if an ASP sends an ASP Active message with an unsupported Traffic Mode 
Type  or a Traffic Mode Type that is inconsistent with the presently 
configured mode for the Application Server.  An example would be a case 
in which the SGP did not support loadsharing.

The "Unexpected Message" error MAY be sent if a defined and recognized 
message is received that is not expected in the current state (in some 
cases the ASP may optionally silently discard the message and not send 
an Error message).  For example, silent discard is used by an ASP if it 
received a DATA message from an SGP while it was in the ASP-INACTIVE 
state. 

The "Protocol Error" error is sent for any protocol anomaly (i.e., 
reception of a parameter that is syntactically correct but unexpected 
in the current situation.

The "Invalid Routing Context" error is sent if a message is received 
from a peer with an invalid (unconfigured) Routing Context value, or if a message is received from a peer without a Routing Context parameter and it is not known by configuration data which Application Servers are referenced.  For this error, the invalid Routing Context(s) MUST be
included.

The "Invalid Stream Identifier" error is sent if a message is received 
on an unexpected SCTP stream (e.g., a Management message was received 
on a stream other than "0").

The "Invalid Parameter Value " error is sent if a message is received 
with an invalid parameter value (e.g., a DUPU message was received with 
a Mask value other than "0").

The "Refused - Management Blocking" error is sent when an ASP Up or 
ASP Active message is received and the request is refused for 
management reasons (e.g., management lockout").

The "ASP Identifier Required" is sent by a SGP in response 
to an ASP Up message which does not contain an ASP Identifier 
parameter when the SGP requires one.  The ASP should resend the
ASP Up message with an ASP Identifier.

The "Invalid ASP Identifier" is send by a SGP in response
to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.

The "Destination Status Unknown" Error MAY be sent if a DAUD is received at an SG enquiring of the availability/congestion status of a destination, and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included.

Diagnostic Information: variable length

    When included, the optional Diagnostic information can be any 
    information germane to the error condition, to assist in 
    identification of the error condition.   The Diagnostic information
    MAY be the first 40 bytes of the offending message.

Error messages MUST NOT be generated in response to other Error 
messages.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 22:08:46 -0500

Ken,

The DAUD stuff sounds very reasonable.

I'm a little confused on errored parameters though.  You say that
an errored parameter must be included in the message.  Say for
example that I receive a Routing Context parameter in an ASPAC
that is 5 bytes long.  What do I place in the ERR message?  A
5-byte long Routing Context?

What ERR do I send when I get an parameter with an invalid or
unsupported tag?

When I send Destination Status Unknown, shouldn't the ERR also
include the RC and even NA value in circumstances where the form
of the APC is not implied by the association?

Are there not also other errors for which Routing Context should
be included, particularly where ASPTM message are being rejected?

--brian

Ken Morneault wrote:                              (Thu, 18 Oct 2001 21:25:34)
> When the SG receives a DAUD with a mask that indicates some bits of the
> point code are wildcarded, the SG shall respond with the status of the point
> codes authorized to be seen by the sender.  The SG will not send an Error
> message for the other point codes. 
> 
> The "Invalid Routing Context" error is sent if a message is received from a
> peer with an invalid (unconfigured) Routing Context value, or if a message
> is received from a peer without a Routing Context parameter and it is not
> known by configuration data which Application Servers are referenced.  For
> this error, the invalid Routing Context(s) MUST be included.
> 
> The "Destination Status Unknown" Error MAY be sent if a DAUD is received at
> an SG enquiring of the availability/congestion status of a destination, and
> the SG does not wish to provide the status (e.g., the sender is not
> authorized to know the status). For this error, the invalid or unauthorized
> Point Code(s) MUST be included.
> 
> 

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

---

---

From: Ken Morneault <[email-masked]>
Date: Thu, 18 Oct 2001 23:37:57 -0400

Brian,

Please see comments below.

Ken

>5-byte long Routing Context?

A 5-byte long Routing Context would be a Parameter Field error
because the length of the parameter would be invalid.  For this
error, the Routing Context would not be included in the ERR message.
This type of error would indicate an implementation issue that
should be dealt with during testing.

>What ERR do I send when I get an parameter with an invalid or

The definitions for the new error values associated with 
parameters did not get in M3UA v9.  They are in SUA v8. 
I have noted to Javier and Greg that these definitions need
to be in M3UA v10.

>of the APC is not implied by the association?

Yes, sorry, I forgot to add this to the proposal.

>be included, particularly where ASPTM message are being rejected?

It could also be added to "Refused - Management Blocking" if
the ERR was in response to an ASPTM message.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Oct 2001 23:05:10 -0500

Ken,

Please see additional comments below...

Ken Morneault wrote:                                          (Thu, 18 Oct 2001 23:37:57)
> should be dealt with during testing.

As the receiver of the message, I can hardly control the
implementation issues of the sender.  Should not the field
in error be identified in the ERR?

> I have noted to Javier and Greg that these definitions need

Is the unsupported tag to be included in the ERR message so
that the sender can determine the source of the error?

> the ERR was in response to an ASPTM message.

There are instances of "Unexpected Message" as well.

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

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 19 Oct 2001 10:09:55 -0400

Brian,

Pls see below.

Ken

>in error be identified in the ERR?

I think the use of Diagnostic Info would be sufficient for 
assisting with implementation bugs.  Are there any other
opinions out there?

>that the sender can determine the source of the error?

same as above.

>There are instances of "Unexpected Message" as well.

agree

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 14:36:54 -0500

Ken,

Ken Morneault wrote:                                          (Fri, 19 Oct 2001 10:09:55)
> assisting with implementation bugs.  Are there any other

Do you mean the first 40 bytes of the message in the DIAG?
What if the field error is not in the first 40 bytes?  Can
I include more?

> >that the sender can determine the source of the error?

Can I include the entire message in the DIAG?

If so, why do I need the separate APC, NA and RC parameters?

--brian

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

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 19 Oct 2001 16:56:54 -0400

You would need separate parameters (at least for APC and RC)
because more than one APC/RC can be in a message.  The
valid APC/RC values would be processed and an error would
be returned for the invalid or "unauthorized" values.

Ken

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 16:23:53 -0500

Ken,

Ok.  I understand now.  That makes sense.

What about DIAG?  Error correlation would
be helpful.  Can we split the difference
and boost MAY to SHOULD?  (With the idea
that if the imp doesn't put DIAG in that
it knows that it is keeping the other side
from correlating?)

--brian

Ken Morneault wrote:                                          (Fri, 19 Oct 2001 16:56:54)

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

---

---

From: Ken Morneault <[email-masked]>
Date: Fri, 19 Oct 2001 22:22:09 -0400

Brian,

I'll take our discussion points and will update the proposal
for inclusion into v10.

Ken

p.s.  boosting MAY to SHOULD is ok with me.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Oct 2001 21:29:48 -0500

Ken,

That pretty much addresses my concerns on this thread.
Thanks for working up the proposal.

--brian

Ken Morneault wrote:                                          (Fri, 19 Oct 2001 22:22:09)

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

---

---

From: Kurt Kite <[email-masked]>
Date: Mon, 22 Oct 2001 10:23:13 -0500

Hi Ken,

A while back I submitted a proposal for the ERR message that you might
want to take a look at. See thread "M3UA version 7 comments." The premise
of the proposal was that the offending message is always included in the ERR
message and that the error code would be unique enough to point out the
erroneous part of the message. One case where the above is not sufficient is where
a parameter can have multiple values (e.g., routing context). In this case, the ERR
message also contains another parameter which only contains the offending value.

Regards,
Kurt

"Brian F. G. Bidulock" wrote:

> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

---