Subject: FW: [Sigtran] Multiple errors inside a one ASPACT

From: Jacques Rajchgod <[email-masked]>
Date: Mon, 11 Feb 2002 10:04:46 -0600

Any idea, anyone?

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
Jacques Rajchgod
Sent: Friday, February 08, 2002 4:25 PM
To: Sigtran
Subject: [Sigtran] Multiple errors inside a one ASPACT

What should the reaction be of a SG receiving two or more errors in one
pack? Ex:

MGC sends ASPACT with two errors:

1) Traffic_mode = all-Zero (Invalid. Must be 1-3)
2) Invalid RC (=all-zero) in a properly formatted RC param

a) Should each error be reacted-to?
b) Or, is there a hierarchy of reactions, such that one error is more
important to react-to than the other, and the SG will react to that more
important one and drop the other?
c) Or?

I don't see anything relating to that question in the various M3UA drafts...

Please, kindly advise...

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

---

From: "Nitin Vairagare" <[email-masked]>
Date: Mon, 11 Feb 2002 11:37:09 -0500

Jacques,

This seems to be purely implementation dependent decision. Ideally any
implementation
should be able to reply/respond to all detected errors (errors defined in
Draft). But I guess their
might be some implementations who would prefer to responding to one error at
a time and abort processing of packet in error. Once the
application/operator fixes first error, next test would reveal
any other errors, which is what naturally users would not like.

Unless an until it is specifically added in any procedures all the errors
can be detected and responded
in any order or any number (minimum 1 error at a time, no matter how many
rounds it takes to detect
all errors).

Adding a similar note in errors section is not bad idea.

Regards
Nitin
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jacques Rajchgod
  Sent: Monday, February 11, 2002 11:05 AM
  To: Sigtran
  Subject: FW: [Sigtran] Multiple errors inside a one ASPACT

  Any idea, anyone?

  Jacques Rajchgod
  MCI Worldcom

  -----Original Message-----

  I don't see anything relating to that question in the various M3UA
drafts...

  Please, kindly advise...

  Jacques Rajchgod
  MCI Worldcom

---

From: Jacques Rajchgod <[email-masked]>
Date: Thu, 14 Feb 2002 17:45:04 -0600

Not sure I understand how that would work...would it be like Case 1 or like
Case 2? Or another way?

Case 1:

a SENDS to b:            ------------ ASP_ACT (with error_1 +
error_2) --------->
a RECEIVES from b:   <---------- Reaction to Error_1 (one from Section
3.6.1) ------ Ignore Error_2 because one-only error can be handled -----
Error Recovery takes place....

Case 2:

a SENDS to b:            ------------ ASP_ACT (with error_1 +
error_2) --------->
a RECEIVES from b:   <---------- Reaction to Error_1 (one from error Section
in M3UA) ------
a RECEIVES from b:   <---------- Reaction to Error_2 (another one from error
Section in M3UA) ------
Error Recovery taking place for Errors_1 and 2...

Text missing in Error Sections on that...
Tks.
Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-7180
E-mail: [email-masked]

  -----Original Message-----
  From: Nitin Vairagare [mailto:[email-masked]]
  Sent: Monday, February 11, 2002 10:37 AM
  To: Jacques Rajchgod; Sigtran
  Subject: RE: [Sigtran] Multiple errors inside a one ASPACT

  Jacques,

  This seems to be purely implementation dependent decision. Ideally any
implementation
  should be able to reply/respond to all detected errors (errors defined in
Draft). But I guess their
  might be some implementations who would prefer to responding to one error
at a time and abort processing of packet in error. Once the
application/operator fixes first error, next test would reveal
  any other errors, which is what naturally users would not like.

  Regards
  Nitin
    -----Original Message-----

    Any idea, anyone?

    Jacques Rajchgod
    MCI Worldcom

    -----Original Message-----

    Please, kindly advise...

    Jacques Rajchgod
    MCI Worldcom

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 14 Feb 2002 18:30:13 -0600

Jacques,

IMO the protocol is not build to handle your case 2.  The
reason is the correlation of error messages with the messages
causing the error.  The implementation need to respond with
one error message only.  The reason for this is that the
receiver of the error message cannot otherwise know how long
to wait to receive subsequent error messages relating to the
same message and, when multiple messages have been sent (as is
permitted by the protocol), the sender might not have
sufficient information in the diagnotic section of the error
message (even with the first 40 bytes of the offending message
included) to correlate error messages with the offending
message.

For this reason, an implementation should only respond with
one ERR message for each offending message.  As the ERR
message only provides for one error cause, the implementation
should only respond to one error condition per offending
message.

It should be clearly pointed out that an implementation's
response to what one implementation considers and error
condition might not cause an error condition for another
implementation.

>    2) Invalid RC (=all-zero) in a properly formatted RC param

As both Traffic Mode and Routing Context are optional
parameters, one implementation may ignore both provided values
if the RC and TMT are implied by the association.

Also, in this example, it might be foolish for an
implementation to generate an error for the Traffic Mode Type
without first having a valid Routing Context to identify the
AS.  (What happens if we add traffic mode type 0 as an
extension later?)  Also, an RC value of zero is not
necessarily invalid.  RC can take on any value.  Some
implementations might use RC==0 to indicate the "default" AS
as was discussed on the list some time ago; however, the only
time that an RC value of zero would be invalid would be if
there is no AS configured or registered which has an RC value
of zero.

The draft provides some mechanism for indicating that the
parameters which are in error in an ERR message.  It might be
possible to include both the RC and TMT in an error message
even though the error condition is "Invalid RC".

The specific circumstances would be needed to give you better
opinion on the validity of an implementation response;
however, IMO you Case 2 should neve be adopted by an
implementation because the receiver of the multiple ERR
messages has no certain way of correlating the two ERR
messages with the offending message anyway.

In error situations such as this, the ERR message is mean as a
diagnostic to management to indicate a configuration or
software error in the system receiving the ERR message as
perceived by the peer.  Except in a very few cases (e.g.,
ERR("ASP Identifier Required")), it is highly unlikely that
the receiver of the ERR message will be able to recover
automatically from the error condition.  Again, this is a
situation where one of the implementations is broken.  Fix one
or both of the implementations so that ERR messages are not
generated.

I only know of two error conditions in M3UA that could be
automatically recovered from: ASP Identifier Requires and No
Configured AS for ASP.  Both of these error conditions can be
avoided altogether by the sender by including the ASP
Identifier parameter in all message that might require it, and
including the RC parameter in all messages that might require
it.  All other error messages indicate a problem with
configuration or a software error.

So, when informing management that an error has occured, the
ERR message carries the error code, the offending parameter,
but the diagnostic also contains the entire (or at least the
first 40 bytes) of the message.  It is possible to scan the
original message in the management system for additional
errors, but IMO the sender of the ERR should specify the first
error encountered which blocked processing of the message.
This indicates to management the first thing which must be
fixed in configuration or software logic.

In general, however, I believe that any implementation
generating two errors in a single message is seriously broken
and needs to be fixed before it can be expected to operate
properly with other implementations.

--brian

Jacques Rajchgod wrote:                                   (Thu, 14 Feb 2002 17:45:04)
> 
>    Not sure I understand how that would work...would it be like Case 1 or
>    like Case 2? Or another way?
>    
>    
>    
>    Case 1:
>    
>    
>    
>    a SENDS to b:            ------------ ASP_ACT (with error_1 + error_2)
>    --------->
>    
>    a SENDS to b:            ------------ ASP_ACT (with error_1 + error_2)
>    --------->
>    
>    a RECEIVES from b:   <---------- Reaction to Error_1 (one from error
>    Section in M3UA) ------
>    
>    a RECEIVES from b:   <---------- Reaction to Error_2 (another one from
>    error Section in M3UA) ------
>    
>    should be able to reply/respond to all detected errors (errors defined
>    in Draft). But I guess their
>    
>    might be some implementations who would prefer to responding to one
>    error at a time and abort processing of packet in error. Once the
>    Unless an until it is specifically added in any procedures all the
>    errors can be detected and responded
>    
>    in any order or any number (minimum 1 error at a time, no matter how
>    many rounds it takes to detect
>    
>    all errors).
>    
>    
>    
>    From: [email-masked] [mailto:[email-masked]]On Behalf
>    Of Jacques Rajchgod
>    From: [email-masked] [mailto:[email-masked]]On Behalf
>    Of Jacques Rajchgod
>    What should the reaction be of a SG receiving two or more errors in
>    one pack? Ex:
>    
>    
>    
>    important to react-to than the other, and the SG will react to that
>    more important one and drop the other?
>    
>    c) Or?
>    
>    
>    

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 15 Feb 2002 10:09:43 -0600

Jacques,

Yes.  Whatever the SG is configured for.  M3UA is supposed to
support traffic modes other than the three provided by prior
arrangement between SG and ASP.  Making TMT optional in ASPAC
permits this.

--brian

Jacques Rajchgod wrote:                                   (Fri, 15 Feb 2002 09:50:28)
> My appreciation.
> 
> Still, question:
> Since the RC and TMT are optional, then, if an ASP does not send them on an
> ASPACT, what does the AS do for TMT? Whatever it is config'ed by default?
> 
> Tks.
> Jacques Rajchgod
> 
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 6:30 PM
> To: Jacques Rajchgod
> Cc: Nitin Vairagare; Sigtran
> Subject: Re: [Sigtran] Multiple errors inside a one ASPACT
> 
> 
> Jacques,
> 

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

---

From: Jacques Rajchgod <[email-masked]>
Date: Fri, 15 Feb 2002 09:50:28 -0600

My appreciation.

Still, question:

Tks.
Jacques Rajchgod

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 6:30 PM
To: Jacques Rajchgod
Cc: Nitin Vairagare; Sigtran
Subject: Re: [Sigtran] Multiple errors inside a one ASPACT

Jacques,

--brian

Jacques Rajchgod wrote:                                   (Thu, 14 Feb 2002
17:45:04)