Subject: Re: [NSIS] draft-qosmodel-controlledload-04

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Jul 2006 22:26:11 +0200

Hi Jerry,

it is true that I haven't read the most recent QSPEC draft when I sent 
this mail. In the meanwhile I did. Please find a few comments below:

Ash, Gerald R (Jerry), ALABS wrote:
> Hi Hannes,
> 
> See below. 
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:[email-masked]] 
>>Sent: Friday, June 30, 2006 8:43 AM
>>To: Bernd Schloer
>>Cc: [email-masked]
>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04
>>
>>Hi Bernd,
>>
>>Bernd Schloer wrote:
>>
>>>Hi,
>>>
>>>the first open issue in the appendix B is about what to do with 
>>>mandatory QSPEC parameters which are not needed for CLS.
>>>
>>>Does a QOSM have to understand (and provide information about) all 
>>>mandatory parameters, even if they are not used?
>>
>>I think the question is wrong. What about the following question:
>>"
>>Does a node that implements a particular QOSM has to understand all
>>mandatory parameters listed in the QSPEC template draft (even if the 
>>QOSM does not make use of them)?
>>"
>>The answer would be "YES" since the QSPEC template draft says that 
>>mandatory parameters have to be understood by every NSIS QoS node.
>>
>>There is only the question what "understands" means.
> 
> 
> IMO you need to more carefully read the QSPEC I-D document.  All
> mandatory QSPEC parameters that are populated in the QSPEC must be
> interpreted by every QNE, which is explained in the QSPEC I-D:
> 
> It says in Section 4.4.1 (Mandatory and Optional QSPEC Parameters) of
> the QSPEC I-D
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt:
> 
> "  Mandatory QSPEC parameters are treated as follows:
> 
>    o A QNI SHOULD populate mandatory QSPEC parameters if applicable to
>      the underlying QOSM.

I don't understand this sentence. What does it mean that a QNI "SHOULD" 
populate parameters if applicable?

>    o QNEs MUST interpret mandatory QSPEC parameters, if signaled."
> 
> Furthermore, it says in Section 4.2 (QSPEC Processing):
> 
> "  a QNE
>    MUST at least interpret all the mandatory parameters in a QSPEC even
>    if it does not support the corresponding QOSM.
> 
>    Mandatory parameters provide a minimal subset of parameters. A
>    QNE MUST either a) strictly interpret a mandatory parameter, or
>    b) remap the parameter and raise the <NON QOSM HOP> flag defined in
>    Section 5.1, where the remapping MUST be specified in the QOSM
>    specification.  Here the terminology 'strictly interpret' means that

What is the difference  between 'strictly interpret' and 'interpret'? In 
the rest of the document you use 'interpret'.

>    the parameter is implemented according to the commonly accepted
>    definition and/or as specified by references given for each QSPEC
>    parameter.  This means that in case a), a <Token Bucket> parameter
>    must be strictly interpreted as a token bucket.  However, in case b),
>    a <token Bucket> parameter may be remapped, perhaps to a <Bandwidth>
>    parameter.
I noticed this text improvement and I am happy to see more text about it.

Still, I have some issues with the section:

I had a problem with this paragraph following the previous one in the 
section. The previous paragraph said
"
However, if a QSPEC arrives at a QNE that does
    not support the QOSM being signaled, it can still understand the
    QSPEC content, at least to a basic degree.
"

When I read through the text I got the impression that the two sections 
relate to each other and in fact they do not. Hence, I suggest to delete 
the previous paragraph since this one contains the info already. You 
might also want to delete the second paragraph as well since it is far 
too obvious to use RFC2119 language: If you don't support even a single 
QOSM then why are you a QOS NSLP node in the first place.

You might want to highlight the following sentence, tough:

"
A QNE MUST interpret all mandatory parameters from this document even
if it does not support the received QoS NSLP message with the indicated 
QOSM.
"

Here is my proposal for the section:

"
4.2 QSPEC Processing

    The QSPEC is opaque to the QoS NSLP processing.  The QSPEC control
    information and the QoS description are interpreted and MAY be
    modified by the RMF in a QNE (see description in [QoS-SIG]).

    The QSPEC contains a QOSM ID, i.e. information on what QOSM is being
    signaled by the QNI.  However, if a QSPEC arrives at a QNE that does
    not support the QOSM being signaled, it can still understand the
    QSPEC content, at least to a basic degree.  This is because mandatory
    parameters have been defined as a common language.  Therefore, a QNE
    MUST at least interpret all the mandatory parameters in a QSPEC even
    if it does not support the corresponding QOSM.

    A QNE MUST either

    a) interpret a mandatory parameter carried in the QSPEC object, or

    b) remap the parameter and raise the <NON QOSM HOP> flag defined in
    Section 5.1, where the remapping MUST be specified in the QOSM
    specification.

    Here the terminology 'interpret' means that
    the parameter is implemented according to the references given for 
each QSPEC parameter.

    If a QSPEC arrives at a QNE that does not support the QOSM being
    signaled, it can still understand the QSPEC content, at least to a
    basic degree. Hence, with case (a), a <Token Bucket> parameter
    must be strictly interpreted as a token bucket.

    In case b), a <token Bucket> parameter may be remapped, perhaps to a
    <Bandwidth> parameter.
"

Btw, have you noticed that the draft has
* a <NON QOSM HOP> flag (Section 5.1)
* a <NON QOSM HOP> parameter (Section 7.2.1)

I think they refer to the same concept...

> 
>    In the latter case, the remapping of the <Token Bucket> to
>    <Bandwidth> must be specified in the QOSM specification document.
>    For example, QOSM X exclusively uses the parameter <Bandwidth>.  It
>    must define a mapping of the mandatory parameter <Token Bucket>.
>    The mapping consists of interpreting the Token Bucket Rate as
>    the <Bandwidth> parameter and disregarding the other Token Bucket
>    parameters.  Clearly, some information contained in the <Token
>    Bucket> parameter is lost by this mapping, and the resulting QoS may
>    not be quite what was intended by the QNI.  Therefore, QOSM X also
>    specifies that the <NON QOSM HOP> flag be raised.  Thus, a QNE using
>    QOSM X is able to make an informed decision whether to admit a
>    reservation described in terms of <Token Bucket>, and at the same
>    time (by means of <NON QOSM HOP>) signals to the QNI/QNR that the
>    exact intention of the QNI may not be met."
> 
> I think this text is pretty clear as to what is required regarding
> interpreting mandatory parameters.  If not, please suggest
> clarifications.

The text in the new draft has improved a lot.
Thanks for the update.

> 
> 
>>Another possible question would be:
>>"
>>Does a node that implements a particular QOSM has to define mappings 
>>from all mandatory parameters listed in the QSPEC template 
>>draft to the QOSM draft (even if the QOSM does not make use of them)?
>>"
>>
>>The answer is "I don't know".
> 
> 
> A QNE must interpret all mandatory parameters, if populated, as
> explained in the above text I quoted.  If a QOSM re-maps a mandatory
> QSPEC parameter, that re-mapping must be defined in the QOSM
> specification.  As stated in Section 4.7 (QOSM Specification
> Requirements):
> 
> "   A QOSM specification MUST define QSPEC parameter behavior for these
>    cases: a) new optional QSPEC parameters the QOSM specification
>    defines, and b) remapping of existing mandatory or optional QSPEC
>    parameters, as described in Section 4.2.  Unless otherwise specified
>    in the QOSM specification document, the behaviors to strictly
>    interpret the mandatory and optional QSPEC parameters are defined in
>    this document through the references to RFCs that precisely define
>    the QSPEC parameter behaviors.  
> 
>    A QOSM specification MUST define how the mandatory parameters are to
>    be mapped onto the QSPEC parameters used by the QOSM, however the
>    mapping MAY result in slight modification to the intended
>    specification when an exact mapping is not possible.  This definition
>    MUST allow a QNE implementing this QOSM to make a decision as to
>    whether a reservation described in terms of mandatory parameters can
>    be admitted.  If for a particular mandatory parameter no mapping can
>    be found that guarantees the desired QoS, the QNE is advised to raise
>    the <NON QOSM HOP> flag.  In other words, for all mandatory
>    parameters a mapping must be defined, but it is acknowledged that
>    this mapping may result in slightly bending the original intention of
>    the QNI."
> 
> I think this text is pretty clear as to what is required.  If not,
> please suggest clarifications.

I understood the token bucket to bandwidth example.

Would the RMD draft, for example, list all mandatory parameters and 
indicate whether it can map them (and how) to parameters used in the RMD 
specification?

Do you think it is awfully realistic for all QNEs to understand all 
mandatory parameters? I could imagine that Attila and Georgios are not 
going to implement stateless interior QNEs in such a way that they 
understand all the mandatory QSPEC parameters. In fact they don't have 
todo it since only edge routers are likely to ever see QoS NSLP messages 
that contain QOSM IDs that they do not understand (otherwise something 
go terribly wrong).

Ciao
Hannes

> 
> Thanks,
> Jerry
>  
> 
>>Ciao
>>Hannes
>>
>>  The QSPEC-draft says in section 5
>>
>>>that
>>>all parameters listed in the next sections are mandatory. The 
>>>QSPEC-draft also
>>>says in section 4.1 that "a given QOSM defines which of the 
>>
>>mandatory and
>>
>>>optional parameters it uses, ..."
>>>
>>>Are there any specific parameters which makes the open issue B.1.1. 
>>>clearer? Following the QSPEC-draft there doesn't seem to be 
>>
>>a conflict, 
>>
>>>if nothing is
>>>done with the unneeded parameters.
>>>
>>>Thanks,
>>>Bernd
> 
> 
> 

_______________________________________________
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:02:56 -0500

Hi Hannes,

See below. 

> Sent: Saturday, July 01, 2006 4:26 PM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]
> > It says in Section 4.4.1 (Mandatory and Optional QSPEC 
> . Parameters) of
> > the QSPEC I-D
> >    o A QNI SHOULD populate mandatory QSPEC parameters if 
> .      applicable to
> >      the underlying QOSM.
> 

It means that a QNI is not required to populate all mandatory parameters.  A QNI would only populated a mandatory parameter if is used by the QOSM supported by the QNI.
 
> the rest of the document you use 'interpret'.

'Strictly interpret' is defined in the text I quoted from Section 4.2 (QSPEC Processing), which is given again in the very next sentences I quoted just below (after you posed your above question :-)

"   Mandatory parameters provide a minimal subset of parameters. A
   parameter."

In the document, the term 'interpret' a mandatory parameter means either a) strictly interpret (as defined above), or b) remap (as defined above).  Perhaps this can be made clearer in the text.
 
> >    However, in case b),
> the previous paragraph since this one contains the info already. 

I'm unclear as to which paragraph/text you are proposing to delete.

> You 

I think it important to state that a QNE MUST support at least one QOSM, even if this is clearly necessary to effectively support QoS-NSLP/QSPEC.

> You might want to highlight the following sentence, though:
> 
> "

I don't see any benefit in redefining what 'interpret' means in the document.  As I mentioned above, the document uses the term 'interpret' to mean that a mandatory parameter is 'interpreted' if is either 'strictly interpreted' or it is 'remapped' (where the remapping must be defined in the QOSM specification document).  OTOH, it might be useful to define a 'remapping' flag to indicated if a mandatory or optional parameter has been remapped by a QNE in the path.
 
> I think they refer to the same concept...

Yes, good catch.  <NON QOSM HOP> is indeed intended to be a flag, and perhaps one of the QSPEC object flags defined in Section 7.1 could be used for this purpose, rather than use a full 32-bit parameter for this purpose, as currently specified in Section 7.2.1.
 
> indicate whether it can map them (and how) to parameters used 

As stated in the QOSM specification requirements in Section 4.7, if a QOSM remaps a mandatory parameter, the remapping must be defined in the QOSM specification document.  If no such remapping is defined, the default behavior is that the QOSM must strictly interpret the mandatory parameter, as defined above.
 
> that contain QOSM IDs that they do not understand (otherwise 

It is up the RMD authors to specify how they want RMD to behave wrt mandatory parameters (and obtain rough consensus, of course).  That is, if a mandatory parameter is remapped and not strictly interpreted, the remapping must be specified in the QOSM specification document.  Otherwise, the QOSM must strictly interpret the mandatory parameters that are not remapped, if they are populated by the QNI.

There are no restrictions on how the remapping must be done, it can be as simple as necessary (but no simpler).

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 3 Jul 2006 13:29:23 +0200

Hi Jerry 

Regarding your last point:
>>Hannes:

>Jerry: It is up the RMD authors to specify how they want RMD 
>> to behave wrt mandatory parameters (and obtain rough 
>> consensus, of course).  That is, if a mandatory parameter 
>> is remapped and not strictly interpreted, the remapping 
>> must be specified in the QOSM specification document.  
>> Otherwise, the QOSM must strictly interpret the mandatory 
>> parameters that are not remapped, if they are populated by the QNI.
>> There are no restrictions on how the remapping must be done, 
>> it can be as simple as necessary (but no simpler).

Georgios:
Jerry, I think that the point raised by Hannes is related to
how the QNE's interior to the RMD domain will have to comply to the
mandatory  descriptions specified in the QSPEC template. 
An interior QNE (in RMD-QOSM) will not process 
the end to end QSpec. The only QSpec that will be processed by the 
interior QNE is the RMD Qsepc that is initiated by the 
ingress node (i.e., QNI for the RMD local session). 
Note that the above observation is valid for all local QOSMs.
However, the above is not allowed due to the following text that is 
included in the QSpec template draft:

"A QNE MUST interpret all mandatory parameters from this document even 
if it does not support the received QoS NSLP message with the 
indicated QOSM."

Therefore, in my opinion it is required to modify the above sentence in
something like:

"A QNE SHOULD interpret all mandatory parameters from this document even 
if it does not support the received QoS NSLP message with the 
indicated QOSM. A QNE that supports a local QOSM, does not have to interpret

all mandatory parameters carried by a QSpec that was generated by a QNI 
located outside the domain that supports the given local QOSM." 

Best regards,
Georgios

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: maandag 3 juli 2006 2:03
To: Hannes Tschofenig
Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); [email-masked];
Kappler Cornelia
Subject: RE: [NSIS] draft-qosmodel-controlledload-04

Hi Hannes,

See below. 

> populate parameters if applicable?

It means that a QNI is not required to populate all mandatory parameters.  A
QNI would only populated a mandatory parameter if is used by the QOSM
supported by the QNI.
 
> What is the difference  between 'strictly interpret' and 'interpret'? 
> In the rest of the document you use 'interpret'.

'Strictly interpret' is defined in the text I quoted from Section 4.2 (QSPEC
Processing), which is given again in the very next sentences I quoted just
below (after you posed your above question :-)

In the document, the term 'interpret' a mandatory parameter means either a)
strictly interpret (as defined above), or b) remap (as defined above).
Perhaps this can be made clearer in the text.
 
> section. The previous paragraph said "
> When I read through the text I got the impression that the two 
> sections relate to each other and in fact they do not. Hence, I 
> suggest to delete the previous paragraph since this one contains the 
> info already.

> too obvious to use RFC2119 language: If you don't support even a 
> single QOSM then why are you a QOS NSLP node in the first place.

I think it important to state that a QNE MUST support at least one QOSM,
even if this is clearly necessary to effectively support QoS-NSLP/QSPEC.

> if it does not support the received QoS NSLP message with the 
> indicated QOSM.
> "
> 

I don't see any benefit in redefining what 'interpret' means in the
document.  As I mentioned above, the document uses the term 'interpret' to
mean that a mandatory parameter is 'interpreted' if is either 'strictly
interpreted' or it is 'remapped' (where the remapping must be defined in the
QOSM specification document).  OTOH, it might be useful to define a
'remapping' flag to indicated if a mandatory or optional parameter has been
remapped by a QNE in the path.
 
> I think they refer to the same concept...

Yes, good catch.  <NON QOSM HOP> is indeed intended to be a flag, and
perhaps one of the QSPEC object flags defined in Section 7.1 could be used
for this purpose, rather than use a full 32-bit parameter for this purpose,
as currently specified in Section 7.2.1.
 
> >>from all mandatory parameters listed in the QSPEC template draft to 
> >>the QOSM draft (even if the QOSM does not make use
> of them)?
> >>"
> >>

As stated in the QOSM specification requirements in Section 4.7, if a QOSM
remaps a mandatory parameter, the remapping must be defined in the QOSM
specification document.  If no such remapping is defined, the default
behavior is that the QOSM must strictly interpret the mandatory parameter,
as defined above.
 
> that contain QOSM IDs that they do not understand (otherwise 

It is up the RMD authors to specify how they want RMD to behave wrt
mandatory parameters (and obtain rough consensus, of course).  That is, if a
mandatory parameter is remapped and not strictly interpreted, the remapping
must be specified in the QOSM specification document.  Otherwise, the QOSM
must strictly interpret the mandatory parameters that are not remapped, if
they are populated by the QNI.

There are no restrictions on how the remapping must be done, it can be as
simple as necessary (but no simpler).

Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 15:21:01 +0200

Hi Jerry,

thanks for your response. Please find my comments below:

~snip~

>> I don't understand this sentence. What does it mean that a QNI
>> "SHOULD" populate parameters if applicable?
> 
> 
> It means that a QNI is not required to populate all mandatory
> parameters.  A QNI would only populated a mandatory parameter if is
> used by the QOSM supported by the QNI.
> 

Let us, for illustration, assume that the QNI is an end host.
The NSIS QoS NSLP daemon does not start signaling on its own.
It gets triggered by something else. An application might trigger the 
QoS NSLP daemon.

The behavior you seem to describe seems to refer to the application 
layer to NSIS daemon interaction. Right?

A QoS NSLP daemon that supports a particular QOSM would only signal what 
the QOSM supports and what it actually received as input.

I think the QSPEC template draft should not describe aspect where the 
QoS NSLP daemon receives (a) more parameter than the QOSM understands or 
(b) not enough parameters required by the QOSM.

>>> "  a QNE MUST at least interpret all the mandatory parameters in
>>>  a QSPEC even if it does not support the corresponding QOSM.
>>> 
>>> b) remap the parameter and raise the <NON QOSM HOP> flag defined
>>> in Section 5.1, where the remapping MUST be specified in the QOSM
>> What is the difference  between 'strictly interpret' and 
>> 'interpret'? In the rest of the document you use 'interpret'.
> 
> 
> 'Strictly interpret' is defined in the text I quoted from Section 4.2
> (QSPEC Processing), which is given again in the very next sentences I
> quoted just below (after you posed your above question :-)
> 
> QNE MUST either a) strictly interpret a mandatory parameter, or b)
> remap the parameter and raise the <NON QOSM HOP> flag defined in 
> In the document, the term 'interpret' a mandatory parameter means
> either a) strictly interpret (as defined above), or b) remap (as
> defined above).  Perhaps this can be made clearer in the text.
> 

I might got confused with the 'interpreted' and 'strictly interpreted' 
terminology because the term 'interpreted' appears many times in the 
entire document with different meanings.

With this mailing list discussion I, however, understood your ideas 
behind it.

>>>  parameter.  This means that in case a), a <Token Bucket> 
>>> parameter must be strictly interpreted as a token bucket. 
>>> However, in case b), a <token Bucket> parameter may be remapped,
>>> perhaps to a <Bandwidth> parameter.
>> 
>> I had a problem with this paragraph following the previous one in
>> the section. The previous paragraph said " However, if a QSPEC
>> arrives at a QNE that does not support the QOSM being signaled, it
>> can still understand the QSPEC content, at least to a basic degree.
>>  "
>> 
>> suggest to delete the previous paragraph since this one contains
>> the info already.
> 
> 

I guess you have later seen my full text proposal below.

> 
>> You might also want to delete the second paragraph as well since it
>> is far too obvious to use RFC2119 language: If you don't support 
>> even a single QOSM then why are you a QOS NSLP node in the first
>> place.
> 
> 
> I think it important to state that a QNE MUST support at least one
> QOSM, even if this is clearly necessary to effectively support
> QoS-NSLP/QSPEC.
> 
> 
>> " A QNE MUST interpret all mandatory parameters from this document
>> even if it does not support the received QoS NSLP message with the
>>  indicated QOSM. "
>> 
>> " 4.2 QSPEC Processing
>> The QSPEC contains a QOSM ID, i.e. information on what QOSM is
>> being signaled by the QNI.  However, if a QSPEC arrives at a QNE
>> that does not support the QOSM being signaled, it can still
>> understand the QSPEC content, at least to a basic degree.  This is
>>  because mandatory parameters have been defined as a common
>> language. Therefore, a QNE MUST at least interpret all the
>> mandatory parameters in a QSPEC even if it does not support the
>> corresponding QOSM.
>> 
>> A QNE MUST either
>> 
>> Here the terminology 'interpret' means that the parameter is
>> implemented according to the references given for each QSPEC
>> parameter.
>> 
>> basic degree. Hence, with case (a), a <Token Bucket> parameter must
>> be strictly interpreted as a token bucket.
>> 
>> In case b), a <token Bucket> parameter may be remapped, perhaps to
>> a <Bandwidth> parameter. "
> 
> 
> document.  As I mentioned above, the document uses the term
> 'interpret' to mean that a mandatory parameter is 'interpreted' if is
> either 'strictly interpreted' or it is 'remapped' (where the
> remapping must be defined in the QOSM specification document).  OTOH,
> it might be useful to define a 'remapping' flag to indicated if a
> mandatory or optional parameter has been remapped by a QNE in the
> path.

I just wanted to be constructive and to propose something.

> 
> 
>> Btw, have you noticed that the draft has * a <NON QOSM HOP> flag
>> (Section 5.1) * a <NON QOSM HOP> parameter (Section 7.2.1)
>> 
> perhaps one of the QSPEC object flags defined in Section 7.1 could be
> used for this purpose, rather than use a full 32-bit parameter for
> this purpose, as currently specified in Section 7.2.1.
> 
> 
>>>  For example, QOSM X exclusively uses the parameter <Bandwidth>.
>>> It must define a mapping of the mandatory parameter <Token
>>> Bucket>. The mapping consists of interpreting the Token Bucket
>>> Rate as the <Bandwidth> parameter and disregarding the other
>>> Token Bucket parameters.  Clearly, some information contained in
>>> the <Token Bucket> parameter is lost by this mapping, and the 
>>> resulting QoS may not be quite what was intended by the QNI.
>>> Therefore, QOSM X also specifies that the <NON QOSM HOP> flag be
>>> raised.  Thus, a QNE using QOSM X is able to make an informed
>>> decision whether to admit a reservation described in terms of
>>> <Token Bucket>, and at the same time (by means of <NON QOSM HOP>)
>>> signals to the QNI/QNR that the exact intention of the QNI may
>>> not be met."
>>> 
>>> I think this text is pretty clear as to what is required
>>> regarding interpreting mandatory parameters.  If not, please
>>> suggest clarifications.
>> 
>> The text in the new draft has improved a lot. Thanks for the
>> update.
>> 
>> 
>>> 
>>>> Another possible question would be: " Does a node that
>>>> implements a particular QOSM has to define mappings
>>> 
>>>> draft to the QOSM draft (even if the QOSM does not make use
>> 
>> of them)?
>> 
>>>> "
>>>> 
>>> explained in the above text I quoted.  If a QOSM re-maps a
>>> mandatory QSPEC parameter, that re-mapping must be defined in the
>>> QOSM specification.  As stated in Section 4.7 (QOSM Specification
>>>  Requirements):
>>> 
>>> "   A QOSM specification MUST define QSPEC parameter behavior for
>>> these cases: a) new optional QSPEC parameters the QOSM
>>> specification defines, and b) remapping of existing mandatory or
>>> optional QSPEC parameters, as described in Section 4.2.  Unless 
>>> otherwise specified in the QOSM specification document, the
>>> behaviors to strictly interpret the mandatory and optional QSPEC
>>> parameters are defined in this document through the references to
>>> RFCs that precisely define the QSPEC parameter behaviors.
>>> 
>>> A QOSM specification MUST define how the mandatory parameters are
>>> to be mapped onto the QSPEC parameters used by the QOSM, however
>>> the mapping MAY result in slight modification to the intended 
>>> specification when an exact mapping is not possible. This
>>> definition MUST allow a QNE implementing this QOSM to make a
>>> decision as to whether a reservation described in terms of
>>> mandatory parameters can be admitted.  If for a particular
>>> mandatory parameter no mapping can be found that guarantees the
>>> desired QoS, the QNE is advised to raise the <NON QOSM HOP> flag.
>>> In other words, for all mandatory parameters a mapping must be
>>> defined, but it is acknowledged that this mapping may result in
>>> slightly bending the original intention of the QNI."
>>> 
>>> I think this text is pretty clear as to what is required.  If
>>> not, please suggest clarifications.
>> 
>>  indicate whether it can map them (and how) to parameters used in
>> the RMD specification?
> 
> 
> As stated in the QOSM specification requirements in Section 4.7, if a
> QOSM remaps a mandatory parameter, the remapping must be defined in
> the QOSM specification document.  If no such remapping is defined,
> the default behavior is that the QOSM must strictly interpret the
> mandatory parameter, as defined above.

Got it as well.

>>  mandatory parameters? I could imagine that Attila and Georgios are
>> not going to implement stateless interior QNEs in such a way that
>> they understand all the mandatory QSPEC parameters. In fact they 
>> don't have todo it since only edge routers are likely to ever see
>> QoS NSLP messages that contain QOSM IDs that they do not understand
>> (otherwise something go terribly wrong).
> 
> 
> mandatory parameters (and obtain rough consensus, of course).  That
> is, if a mandatory parameter is remapped and not strictly
> interpreted, the remapping must be specified in the QOSM
> specification document.  Otherwise, the QOSM must strictly interpret
> the mandatory parameters that are not remapped, if they are populated
> by the QNI.
> 
> There are no restrictions on how the remapping must be done, it can
> be as simple as necessary (but no simpler).

I will review the QOSM documents to see how these remapping have been 
defined.

Ciao
Hannes

> Thanks, Jerry
>> Ciao Hannes
>>> Thanks, Jerry
>>>> Ciao Hannes
>>>>> that all parameters listed in the next sections are
>>>>> mandatory. The QSPEC-draft also says in section 4.1 that "a
>>>>> given QOSM defines which of the
>>>> 
>>>> mandatory and
>>>> 
>>>> 
>>>>> Are there any specific parameters which makes the open
>> 
>> issue B.1.1.
>> 
>>>>> if nothing is done with the unneeded parameters.
>>>>> 
>>>>> Thanks, Bernd
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Jul 2006 16:36:40 +0200

Hi Georgios,

please find my comment below:

> located outside the domain that supports the given local QOSM." 
Something along these lines would probably be more realistic, I guess.

Ciao
Hannes

>>>>mandatory parameters listed in the QSPEC template draft
>>
>>(even if the
>>
>>>   parameter