RE: [NSIS] QoS NSLP INFO_SPEC and error codes

["Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>]

Hi Andrew,

See comments below.

Thanks,
Jerry

> -----Original Message-----
> From: Andrew McDonald [mailto:[e-mail]] 
> Sent: Monday, May 08, 2006 5:52 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [NSIS] QoS NSLP INFO_SPEC and error codes
> 
> Hi Jerry,
> 
> I've been looking at some scribbled notes I've got, and subsequent
> e-mails on the subject.
> 
> At the breakfast meeting, the thing I seem to have jotted down was
> "use the Optional Error-Specific Information" component of the 
> INFO_SPEC for QSpec information.
> 
> However, in some subsequent off-list discussion, I think I went
> off this idea a bit. The main problem is that you drag information
> about QSPEC parameters into the NSLP. Stacking may also create
> issues with this.
> 
> The subsequent suggestion was, I believe, that the QoS NSLP should 
> provided a limited set of error codes (e.g. "Total Success", "Partial 
> Success", "Total Failure"). The QSpec parameters then have a flag to 
> indicate which (if any) parameters failed to be satisfied. This is 
> signalled back to the QNI in the response. The QNI then makes the 
> determination about whether to continue or tear down the partial 
> reservation that has been established.
> 
> Does that sound reasonable? Does it fit with other peoples thoughts?

This sounds reasonable to me.  We need to nail down how this error code
functionality will work.  

What is now specified in the QSPEC I-D (Section 4.5.1 in
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt) is as
follows:

"When an RMF cannot interpret the QSPEC because the coding is
   erroneous, it raises corresponding flags in the QSPEC.  The 'error
   flags' are located in each QSPEC Object and in each parameter.  If
   such a flag is set, at least one QNE along the data transmission path
   between the QNI and QNR cannot interpret a mandatory or optional
   QSPEC parameter or the QSPEC object for any reason, such as a
   protocol error, QNE fault, etc.  In this case, more detailed error
   information may be given in the QoS NSLP error message.  That is, if
   possible the RMF must communicate error details to the QoS NSLP
   processing.  QoS NSLP [QoS-SIG] describes how the erroneous message
   is handled further.

   As stated in Section 5.1.3.6 (INFO_SPEC) of [QoS-SIG]:
   "Values in the error subcode field are defined in each QOSM
   specification separately. The default value for the subcode is 0x00.
   A default value means that the QoS model does not want or does not
   need to give more information about the error/result, anything else
   in the subcode must be defined in the QoS model specification."

   That is, any additional error codes beyond those defined in [QoS-SIG]
   MUST be defined in individual QOSM specifications."

I suggest this be modified along the lines of your suggestion so that
QSPEC/RMF-specific codes are identified in the QSPEC I-D.  That is, for
example, the 4-bit error class is defined in QoS-NSLP as follows:

"0x06 - QSPEC/RMF-specific Error"
This error is set by QoS-NSLP if QSPEC/RMF sets an 8-bit
QSPEC/RMF-specific error subcode, specified below.  Perhaps other
QSPEC/RMF-specific error codes can be defined in QoS-NSLP based on
QSPEC/RMF specific failure conditions.

Within the 4-bit error class "0x06 - QSPEC/RMF-specific Error", the
"8-bit QSPEC/RMF-specific error subcodes" are defined and set by
QSPEC/RMF; for example:

0x02 - <Bandwidth> cannot be met
0x03 - <Path Latency> cannot be met
0xab - <Path Jitter> cannot be met
0xcd - <Path PLR> cannot be met
0xef - <Path PER> cannot be met 
etc.

These '8-bit QSPEC/RMF-specific error subcodes' pertain to QSPEC
parameters and are defined within the QSPEC I-D.  Additional '8-bit
QSPEC/RMF-specific error subcodes' pertaining to QSPEC parameters
defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should
also be defined in the QOSM-specific I-Ds.

Does this sound OK?  If not, please make a counter proposal.

> Does the 'E' flag in the QSPEC parameters already provide the 
> necessary QSpec information? (not clear if 'error' covers
> 'reservation could not be satisfied')

As above, the 'E flag' would be set by QSPEC/RMF if some error condition
arises wrt a QSPEC parameter.  The '8-bit QSPEC/RMF-specific error
subcode' is set by QSPEC/RMF to a specific value if additional
information on the error is to be conveyed to the QNI.
 
> Something I've also noticed in looking at the QSpec template 
> document is that the introduction talks about its role as a
> 'toolbox', but does not talk about the processing flexibility aspect
> (e.g. the fact that it allows for nodes that support different
> subsets of QSpec parameters).

Good point, the 'different subsets of QSPEC parameters' functionality
needs to be added in the introduction.  I think we need to revise
somewhat the 'toolbox' description to clarify.

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis