Subject: [NSIS] QoS NSLP INFO_SPEC and error codes

From: Andrew McDonald <[email-masked]>
Date: Thu, 09 Mar 2006 17:23:00 +0000

A few comments in the area of the INFO_SPEC object and error codes.

Draft -10 doesn't seem to have appeared yet, but these comments apply 
equally to -09 and -10.

Protocol errors include:
          *  0x08 - Unknown QSPEC type: the QoS Model ID refers to a QoS
                    Model which is not known by this QNE.
It's not clear to me that is a protocol error. Firstly, QoS Model ID is 
inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly, my 
understanding from the QSPEC template is that, in the case of an unknown 
QoS Model ID, the RMF should continue to process mandatory QSPEC parameters.

Transient failure codes include:
          *  0x01 - Requested resources not available
          *  0x02 - Insufficient bandwidth available
          *  0x03 - Delay requirement cannot be met

Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since they 
directly relate to information in the QSPEC rather than the main QoS 
NSLP data?

There are two transient error codes:
          *  0x05 - Resources pre-empted
          *  0x09 - Reservation pre-empted
but I don't see how these differ.

Similarly, the difference between these two is unclear to me:
          *  0x06 - No GIST reverse-path forwarding state
          *  0x08 - No path state for RESERVE, when doing a receiver-
                    oriented reservation

The Information/Success/ProtocolError codes have a sentence of 
explanation as well as the 'error name'. Would it be useful to add 
something for the other codes too? I eventually found what "RII 
conflict" was, but I'm still not sure about "Mismatch synchronization 
between end-to-end RESERVE and intra-domain RESERVE".

It is not totally clear which errors the optional error specific 
information is appropriate for. I think it would be useful to list them 
explicitly (otherwise there is some ambiguity about whether you are 
decoding an 'Object Value Info' or 'Object Type Info'.

Section 5.3.5 on the INFO_SPEC object seemed overly long (it is the 
longest description of any QoS NSLP object, though I would have thought 
it was one of the least complicated). Most of the text in the sections 
5.3.5.x is repeated. Can we try to trim this text down a bit? I'd rather 
see some text saying what the usual processing of an INFO_SPEC is, and 
then identify any differences that occur due to the different error 
classes. Also, a sizeable amount of the text in 5.3.5.x is a repeat of 
the error code lists from 5.1.3.6 - it's probably better to keep these 
in one place (either 5.1.3.6 or 5.3.5).

regards,
Andrew

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 16 Mar 2006 11:41:33 -0600

Hi Andrew, All,

Please see comments in line:

> -----Original Message-----
> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Thursday, March 09, 2006 12:23 PM
> To: Jukka MJ Manner; Georgios Karagiannis
> Cc: [email-masked]
> Subject: [NSIS] QoS NSLP INFO_SPEC and error codes
> 
>           *  0x08 - Unknown QSPEC type: the QoS Model ID refers to a
>                     QoS Model which is not known by this QNE.
> It's not clear to me that is a protocol error. Firstly, QoS Model ID
> is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly,
> my understanding from the QSPEC template is that, in the case of an
> unknown QoS Model ID, the RMF should continue to process mandatory 
> QSPEC parameters.

Jerry> Both comments are correct.  This error subcode should probably be
deleted.  Should it be replaced by some other type of error involving
QOSM ID (none come to mind for me)?
 
> Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since
> they directly relate to information in the QSPEC rather than the
> main QoS NSLP data?

Jerry> I agree that 0x02 and 0x03 are specific cases of 0x01, but they
are not IMO "QoS model specific" since <Bandwidth> is a mandatory QSPEC
parameter and <Path Latency> is an optional QSPEC parameter.  Similarly,
perhaps "cannot be met" error subcodes should be defined for <Path
Jitter>, <Path PLR>, and <Path PER> parameters, which are also optional
QSPEC parameters.  

Perhaps it's better to describe the '4-bit error class', '12-bit error
codes', and '8-bit QoS model-specific error subcode' in terms of
"QSPEC/RMF-specific" rather than "QoS Model specific".

So then the 4-bit error class 
"0x06 - QoS model-specific Error" 
becomes 
"0x06 - QSPEC/RMF-specific Error".

And also redefine the 
"8-bit QoS model-specific error subcode" 
as
"8-bit QSPEC/RMF-specific error subcode".

Then within the 4-bit error class "0x06 - QSPEC/RMF-specific Error" the
following 12-bit error code is defined (now a 'transient failure code"):
0x01 - Requested resources not available

And within that 12-bit error code the following "8-bit
QSPEC/RMF-specific error subcodes" are defined:

0x02 - <Bandwidth> cannot be met
0x03 - <Path Latency> cannot be met
and perhaps others, e.g.,
0xab - <Path Jitter> cannot be met
0xcd - <Path PLR> cannot be met
0xef - <Path PER> cannot be met 
etc.

These error codes pertaining to mandatory/optional QSPEC parameters
(defined within the QSPEC I-D) can either be defined in the QoS-NSLP I-D
(preferably IMO) or alternatively within the QSPEC I-D.
 
Additional 'QSPEC/RMF-specific Errors' and their '12-bit error code' and
'8-bit QSPEC/RMF-specific error subcodes' pertaining to (optional) 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.

Should any of the above be identified as issues to be discussed at
IETF-65?

Please let me know what you think.

Thanks,
Regards,
Jerry