Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Jul 2006 10:47:07 +0200

Hi QSPEC authors,

I tried to figure out whether the QSPEC template draft could be used for 
the AAA work. The QSPEC QoS object header raised a few questions:

* Why do you need a length field if all the objects just have a fixed 
length?

* Why do you need an 'M' bit? Whether a parameter is mandatory or not 
can easily derived from the Parameter ID.

* Why do you need the 'T' flag? I don't think that the concept is 
actually useful.

In Section 4.5.3 you write:

4.5.3 QSPEC Tunneled Parameter T-Flag

    Each QSPEC parameter has an associated 'tunneled-parameter T-flag'.
    When a RESERVE message is tunneled through a domain, QNEs inside the
    domain cannot update read-write parameters.

[hannes] QNEs MUST NOT update the parameters. That's the idea of tunneling.

   The egress QNE in a
    domain has two choices: either a) it is configured to have the
    knowledge to update the parameters correctly,

[hannes] What type of update are you looking for?
The reservation within the tunneled region is a separate and independent 
reservation.

  or b) it cannot update
    the parameters.  In the latter case it MUST set the
    tunneled-parameter T-flag to tell the QNI (or QNR) that the
    information contained in the read-write parameter is most likely
    incorrect (or a lower bound).

[hannes] Which parameters are incorrect?

   The T-flag is interpreted by the QNI,
    ingress QNE (start of tunnel in a domain), egress QNE (end of tunnel
    in a domain), or QNR.

[hannes] There are now three 'T' bits flying around in related documents:

* T-bit set (RESERVE tear): QoS NSLP
* T-bit in the NSIS Tunnel ID
* T-bit in the QSPEC draft

Neigther the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge, not 
use the T-bit of the QSPEC document.

* Why do you need to put error specific flag in every object (namely 'E 
and N flag)? Errors should be the exception rather than the norm. I 
would do something different, namely to put an error object with a list 
of the Parameter IDs in it.

Regarding the parameter encoding:

You might want to change the description with regard to the Parameter ID 
field. Change from:

"
7.2.1 <NON QOSM Hop> Parameter

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|E|0|T|           0           |r|r|r|r|          1            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | NON QOSM Hop  |                 Reserved                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

to:

"
7.2.1 <NON QOSM Hop> Parameter

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|E|0|T|00000000000000000000000|r|r|r|r|          1            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | NON QOSM Hop  |                 Reserved                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

or:
"
7.2.1 <NON QOSM Hop> Parameter

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|E|0|T|     Parameter ID      |r|r|r|r|      Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | NON QOSM Hop  |                 Reserved                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter ID: 0

Length: 1

"

The Parameter ID is 12 bits long. Is it also encoded in network byte 
order? The same is true for the Length field.

The draft only says that
"Network byte order ('big-endian') for all 16- and 32-bit integers, as
    well as 32-bit floating point numbers, are as specified in [RFC1832,
    IEEE754, NETWORK-BYTE-ORDER].
"

Ciao
Hannes

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sun, 2 Jul 2006 19:06:56 -0500

Hi Hannes,

See below. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Sunday, July 02, 2006 4:47 AM
> To: NSIS
> Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header
> 
> Hi QSPEC authors,
> 

The length of various QSPEC parameters is not fixed.  E.g., compare Section 7.2.5 <Token Bucket> (length=5) to Section 7.2.3 <Bandwidth> (length=1).
> can easily derived from the Parameter ID.

We were advised that the M flag should be specified for easier QSPEC processing.  In addition, new QSPEC versions specifying new mandatory parameters and/or unrecognized optional parameters could also mandate that this flag be used.
 
> The reservation within the tunneled region is a separate and 

Not sure what you mean by "separate and independent reservation".  We're talking about an end-to-end reservation where one domain may tunnel the Initiator QSPEC through the domain.  With respect to the 'update', it refers to the egress QNE in the domain updating a mandatory or optional QSPEC parameter in the Initiator QSPEC.  E.g., if the <bandwidth> parameter (a mandatory QSPEC parameter) is specified in the <QoS Available> object in the Initiator QSPEC, and the Initiator QSPEC is tunneled through a domain, the egress QNE in the domain may be configured to update this parameter.  If it cannot update this parameter, then it needs to set the T-Flag to so indicate.
 
> [hannes] Which parameters are incorrect?

If in the above example, the egress QNE in the domain is unable to update <bandwidth> in the <QoS Available> object, it must then set the T-flag for the <bandwidth> parameter.

> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my 
> knowledge, not 

The T-bit in the QSPEC draft is strictly for use by the RMF in QoS processing, so I think its use is restricted to implementation of the NSLP/QSPEC/RMF procedures.  However, you raise a good point about 3 different definitions for 'T-bit', and we need to be sure there is no confusion resulting from this.
 
> of the Parameter IDs in it.

The use of E-Flag is definitely the exception rather than the norm.  IMO the approach defined in Section 4.5.1 is a reasonable approach, that is, to flag an error according to a specific QSPEC parameter, if possible.  However, as stated in Section 4.5.1, in some error situations it may not be possible to set the E-Flag for a QSPEC parameter, although it may be possible to still set the E-Flag for the QSPEC object.  The INFO_SPEC in this case does carry the QSPEC with the erroneous parameters flagged within it.  The alternative you suggest I think is similar to this approach (this approach agreed to after a very lengthy discussion on error codes).
 
> 7.2.1 <NON QOSM Hop> Parameter

I'm not sure I get the point you're making here.  For the <NON QOSM HOP> case, however, perhaps this flag should be coded as a QSPEC object flag and not a 32-bit parameter, as suggested in the previous message.

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 10:20:13 +0200

Hi Jerry,

please find my response below:

Ash, Gerald R (Jerry), ALABS wrote:
> Hi Hannes,
> 
> See below.
> 
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[email-masked]] Sent: Sunday, July 02, 2006 4:47
>> AM To: NSIS Subject: [NSIS] QSPEC Comment: QSPEC QoS Object Header
>> 
>> Hi QSPEC authors,
>> 
>> I tried to figure out whether the QSPEC template draft could be
>> used for the AAA work. The QSPEC QoS object header raised a few
>> questions:
>> 
>> * Why do you need a length field if all the objects just have a
>> fixed length?
> 
> 
> The length of various QSPEC parameters is not fixed.  E.g., compare
> Section 7.2.5 <Token Bucket> (length=5) to Section 7.2.3 <Bandwidth>
> (length=1).

No, I meant that the Parameter ID would immediately tell you the length 
of the respective attribute.

For every object the length of the object cannot be variable.

> 
>> * Why do you need an 'M' bit? Whether a parameter is mandatory or
>> not can easily derived from the Parameter ID.
> 
> 
> We were advised that the M flag should be specified for easier QSPEC
> processing.

I don't see the big advantage. Instead of looking at the flag and then 
processing the Parameter ID I would have to look at the Parameter ID and 
then see immediately whether it is a mandatory attribute or not.

   In addition, new QSPEC versions specifying new mandatory
> parameters and/or unrecognized optional parameters could also mandate
> that this flag be used.

The current text in the draft does not provide a solid story about the 
QSPEC version updates. It says
"
Additional mandatory parameters may be defined in the future.
    However, since this requires an update of all QNEs, this should be
    considered carefully.
"

If this is the requirement then it can never happen that a QNE sees a 
mandatory parameter that it does not understand.

>>  When a RESERVE message is tunneled through a domain, QNEs inside
>> the domain cannot update read-write parameters.
>> 
>> The egress QNE in a domain has two choices: either a) it is
>> configured to have the knowledge to update the parameters
>> correctly,
>> 
>> [hannes] What type of update are you looking for? The reservation
>> within the tunneled region is a separate and independent 
>> reservation.
> 
> 
> Not sure what you mean by "separate and independent reservation".

See Section 4.6 of
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt

Figure 12 in ection 4.6 of
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt
is particularly nice since it shows that the RESERVE'/RESPONSE' within 
the domain are independent of the E2E RESERVE/RESPONSE.

> We're talking about an end-to-end reservation where one domain may
> tunnel the Initiator QSPEC through the domain.  With respect to the
> 'update', it refers to the egress QNE in the domain updating a
> mandatory or optional QSPEC parameter in the Initiator QSPEC.  E.g.,
> if the <bandwidth> parameter (a mandatory QSPEC parameter) is
> specified in the <QoS Available> object in the Initiator QSPEC, and
> the Initiator QSPEC is tunneled through a domain, the egress QNE in
> the domain may be configured to update this parameter.

Why would it want to update the parameter?

   If it cannot
> update this parameter, then it needs to set the T-Flag to so
> indicate.

If he wants to update the parameter why would there be a problem with it?

> 
> 
>> or b) it cannot update the parameters.  In the latter case it MUST
>> set the tunneled-parameter T-flag to tell the QNI (or QNR) that the
> If in the above example, the egress QNE in the domain is unable to
> update <bandwidth> in the <QoS Available> object, it must then set
> the T-flag for the <bandwidth> parameter.
> 
> 
>> The T-flag is interpreted by the QNI, ingress QNE (start of tunnel
>> in a domain), egress QNE (end of tunnel in a domain), or QNR.
>> 
>> * T-bit set (RESERVE tear): QoS NSLP * T-bit in the NSIS Tunnel ID 
>> Neither the QoS NSLP nor the NSIS Tunnel ID does, to my knowledge,
>> not use the T-bit of the QSPEC document.
> 
> 
> The T-bit in the QSPEC draft is strictly for use by the RMF in QoS
> processing, so I think its use is restricted to implementation of the
> NSLP/QSPEC/RMF procedures.  However, you raise a good point about 3
> different definitions for 'T-bit', and we need to be sure there is no
> confusion resulting from this.
> 

Why does the RMF need this info?

> 
>> * Why do you need to put error specific flag in every object 
>> (namely 'E and N flag)? Errors should be the exception rather than
>> the norm. I would do something different, namely to put an error
>> object with a list of the Parameter IDs in it.
> 
> 
> The use of E-Flag is definitely the exception rather than the norm.
> IMO the approach defined in Section 4.5.1 is a reasonable approach,
> that is, to flag an error according to a specific QSPEC parameter, if
> possible.  However, as stated in Section 4.5.1, in some error
> situations it may not be possible to set the E-Flag for a QSPEC
> parameter, although it may be possible to still set the E-Flag for
> the QSPEC object.  The INFO_SPEC in this case does carry the QSPEC
> with the erroneous parameters flagged within it.  The alternative you
> suggest I think is similar to this approach (this approach agreed to
> after a very lengthy discussion on error codes).
> 

So, what you are going todo?

>> You might want to change the description with regard to the 
>> Parameter ID field. Change from:
>> 
>> " 7.2.1 <NON QOSM Hop> Parameter
>> 
>> 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 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>> NON QOSM Hop  |                 Reserved                      | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
>> 
>> 
>> to:
>> 
>> " 7.2.1 <NON QOSM Hop> Parameter
>> 
>> 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 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>> NON QOSM Hop  |                 Reserved                      | 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
>> 
>> 
>> or: " 7.2.1 <NON QOSM Hop> Parameter
>> 
>> 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 
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>> NON QOSM Hop  |                 Reserved                      | 
>> The Parameter ID is 12 bits long. Is it also encoded in network
>> byte order? The same is true for the Length field.
>> 
>> The draft only says that "Network byte order ('big-endian') for all
>> 16- and 32-bit integers, as well as 32-bit floating point numbers,
>> are as specified in [RFC1832, IEEE754, NETWORK-BYTE-ORDER]. "
> 
> 
> I'm not sure I get the point you're making here.

The point is: What is the encoding of the parameters.
The text and the figure does not provide enough details to figure it out.

   For the <NON QOSM
> HOP> case, however, perhaps this flag should be coded as a QSPEC
> object flag and not a 32-bit parameter, as suggested in the previous
> message.

Ciao
Hannes

> Thanks, Jerry
>> Ciao Hannes

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 3 Jul 2006 19:06:23 -0500

Hi Hannes,

See below.

> Figure 12 in Section 4.6 of

I think the interpretation of tunneling in the QSPEC I-D is consistent with this description in QoS-NSLP.  I think I know what you mean by "independent", but what happens inside the local domain and outside the local domain is all part of the same NSIS reservation from QNI to QNR.  In particular, the QOSM treatment in the local domain is not independent of the QOSM treatment outside the local domain, and specifically what QOSM procedures are followed by the QNI (or QNR).
 
> Why would it want to update the parameter?

Well, as you know, <bandwidth> is a mandatory parameter and therefore it is mandatory to update the <bandwidth> parameter in the Initiator QSPEC, since in this example <bandwidth> is populated in the Initiator QSPEC.  
 
> If he wants to update the parameter why would there be a 

There may be a problem because the egress QNE in the local domain may not have the necessary information to update the <bandwidth> parameter.  This is because the Initiator QSPEC is tunneled through the local domain, and there is no update of the <bandwidth> parameter in the Initiator QSPEC in the local domain.  However, the T-Flag allows the egress QNE in the local domain to mark the <bandwidth> parameter in the Initiator QSPEC to indicate that it "cannot be updated".  IMO, this is a way for a local QOSM in a local domain to "ignore" mandatory QSPEC parameters populated in the Initiator QSPEC if necessary.  That is, the egress QNE in the local domain can set the T-flag for any mandatory parameters that cannot be interpreted in the local domain.  IMO this point addresses several other comments today about a QOSM "ignoring" mandatory parameters.  Mandatory parameters can, in effect, be "ignored" if necessary with the use of the T-flag.  It is then up to the QNI (or QNR) to decide if the reservation is accepted or rejected, in light of T-flags being set for some (possibly mandatory) parameters.
 
> Why does the RMF need this info?

The RMF needs to know if a mandatory parameter "was not interpreted" by a local domain (e.g., as indicated by the T-flag being set), in order to decide whether to accept or reject the reservation at the QNI (or QNR).

> So, what you are going todo?

We're going to follow what's stated in Section 4.5.1, unless there is some agreement to change that.
 
> The text and the figure does not provide enough details to 

OK, can you suggest text to fix the problem you see.

Thanks,
Jerry