Subject: [NSIS] Parsing QSpec with Initiator/Local QSpec

From: Andrew McDonald <[email-masked]>
Date: Tue, 03 Apr 2007 10:24:21 +0100

Hi Jerry,

I'm currently trying to work out how to correctly parse QSpec objects 
where there are both Local and Initiator QSpecs.

My understanding is that the format is roughly:
QSpec Header
[1 or more QSpec objects]
QSpec Header
[1 or more QSpec objects]

On my current understanding, I seem to be able to reach a situation 
where I'm processing the first set of QSpec objects, and I don't know 
whether the next thing I'm looking at is another QSpec object or the 
second QSpec header.

I thought that the combination of QoS NSLP message type and QSpec Proc 
(Msg Seq + Obj Comb) should tell me what set of QSpec objects to expect 
in each case. However, there is one case where this is unclear, i.e.:
Message Sequence = 1
Object Combination = 2
QoS NSLP Message = RESERVE
(see section 5.3.2)

I'm a little unclear, but I think the (Min QoS) is not always there. Is 
that a correct interpretation?

If so, then at this point in processing the QSpec I can't be sure 
whether the next thing I expect is a Min QoS object or a second QSpec 
header.

regards,
Andrew

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

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Wed, 11 Apr 2007 15:48:47 -0500

Hi Andrew,

I've been discussing this with Cornelia, and she made a couple of good suggestions to resolve the issue you raise.  The issue you raise is a very practical one: How does the RMF know it is parsing a new QSPEC rather than the Minimum QoS Object. The QSPEC header field "QSPEC Procedure" does not allow to determine the number of QSPEC objects as it leaves open whether Minimum QoS is present or not.  Therefore we propose two solutions to the issue, and maybe we should do both for redundancy:

1. In Section 5.3.2 in http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt we add another value "4" to the Obj Cmb field which makes unique the mapping QSPEC Procedure -> number and type of QoS Objects, as follows:

   ID| QUERY            | RESERVE                    | RESPONSE
   ---------------------------------------------------------------------
   1 |QoS Des.          | QoS Des.                   | QoS Res.
   2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,Min QoS  | QoS Res.,QoS Avl.
   3 |QoS Des.          | QoS Des.,QoS Avl.          | QoS Res.,QoS Avl.
   4 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl.          | QoS Res.

The descriptive words would be changed accordingly.

2. We add a field "QSPEC length" in the Reserved portion of the QSPEC header (note we have a corresponding field for the QoS Objects), 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Vers. |Q. Type|  QSPEC Proc.  |I|r|          Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

'Version' and 'QSPEC Type' are reduced down to 4 bits (16 values) to allow 14 bits for 'Length' (QSPEC Proc. and I are the same, r is reserved).

We'd like to get your reaction/suggestions and that of other implementers regarding this proposal.

Thanks,
Regards,
Jerry

> -----Original Message-----
> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 5:24 AM
> To: ASH, GERALD R, ATTLABS; nsis
> Subject: Parsing QSpec with Initiator/Local QSpec
> 
> Hi Jerry,
>

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 12 Apr 2007 10:00:05 +0100

Hi Jerry,

ASH, GERALD R, ATTLABS wrote:
> I've been discussing this with Cornelia, and she made a couple of
> good suggestions to resolve the issue you raise.  The issue you raise
> is a very practical one: How does the RMF know it is parsing a new
> QSPEC rather than the Minimum QoS Object. The QSPEC header field
> "QSPEC Procedure" does not allow to determine the number of QSPEC
> objects as it leaves open whether Minimum QoS is present or not.
> Therefore we propose two solutions to the issue, and maybe we should
> do both for redundancy:
> 
> 1. In Section 5.3.2 in
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt we add
> another value "4" to the Obj Cmb field which makes unique the mapping
> QSPEC Procedure -> number and type of QoS Objects, as follows:
> 

This looks like a sensible idea.

> 2. We add a field "QSPEC length" in the Reserved portion of the QSPEC
> header (note we have a corresponding field for the QoS Objects), as
> follows:
> 
>      0                   1                   2                   3
> 'Version' and 'QSPEC Type' are reduced down to 4 bits (16 values) to
> allow 14 bits for 'Length' (QSPEC Proc. and I are the same, r is
> reserved).

 From a packet parsing perspective having some sort of length field is a 
useful. If only (1) was implemented, then you need to look at the 
message type, obj cmb and have a look-up table to know how many objects 
to expect. This may have extensibility issues (i.e. you can't parse the 
packet if the message-type/obj-cmb pair is not in your look-up table).

I'd suggest going with both (1) and (2).

A possible variation of (2) would be to put the number of QSpec Objects 
instead of the length. This would allow you to have a shorter 'length' 
field. However, I think the proposal you give fits better with the 
packet structures in other parts of the protocol (GIST, QoS NSLP, QSpec 
headers and object headers) where 14-bit length fields are used.

regards,

Andrew

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 12 Apr 2007 15:50:47 +0100

Hi Jerry (again),

A further comment below:

> headers and object headers) where 14-bit length fields are used.

Having just been looking at the QoS NSLP and GIST drafts again, I 
realise that I was slightly mistaken. They actually use 12-bit length 
fields in the object headers, not 14-bits. I'd suggest reducing the 
Length similarly to 12 bits here, since the maximum length must be less 
than the maximum length of the QoS NSLP QSPEC object.
i.e. I'd make the header:
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers. |Q. Type|  QSPEC Proc.  |I|r|r|r|        Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

regards,

Andrew