Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st?

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 27 Jul 2006 08:31:35 +0200

Hannes,

you raise an important aspect here.

|What is missing today in QOSMs is a mapping of mandatory parameters to 
|the QOSM behavior. If you look at the QOSMs being standardized today 
|then they do not necessarily use all mandatory parameters. It 
|is, IMHO, important to specify what a node that implements a 
|particular QOSM would do when it receives a message with a QSPEC 
|object that contains an unknown  QOSM. For example, what do all 
|the currently specified mandatory parameters mean in the context of 
|RMD? I have asked this question in the past already; I never 
|saw an answer.

The draft should at least say, that the reservation must be 
released/refused if a node doesn't understand a QOSM. If a 
different behaviour is operated, every implementor of a QOSM 
may design own interworkings and if several different 
implementations appear along a path, the (usually value added) 
service may not behave in way as expected by the QNI.

A reservation should only continue if there's a standardised 
interworking between different QOSM's along a path. I don't 
however favour a solution, where everey standardised QOSM 
is obliged to interwork with every other standardised 
QOSM. Standardisation of these interworkings should follow 
the trends of the operational Internet to this regard. 
Interworkings between a few popular QOSMs may be useful.

Regards,

Rüdiger

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:01 +0200

Hi Ruediger,

Geib, Ruediger wrote:
> released/refused if a node doesn't understand a QOSM.

Well, that's not what a node should do. Instead it should try todo 
anything it can to produce a meaningful QoS reservation whereby the idea 
is that this 'meaningful' reservation can be accomplished by just 
looking at the mandatory QoS parameters of a QSPEC object (with the 
details of that particular QOSM being unknown).

  If a
> service may not behave in way as expected by the QNI.

The QNI might still learn that there are some domains along the end to 
end path that did not support the QOSM it signaled. It might still 
accomplish some QoS treatment although it will not be the one it 
initially expected. This is our 'better than nothing QoS' (inline with 
the 'better than nothing security' approach).

> interworking between different QOSM's along a path.

That's the place where the QSPEC template guys would disagree with you.
If the group would only worry about this aspect then we wouldn't need 
the QSPEC template draft.

  I don't
> QOSM.

Sure. That would put a massive burden on new QOSMs and it might not be 
feasible given that other SDOs can also define their QOSMs.

  Standardisation of these interworkings should follow
> Interworkings between a few popular QOSMs may be useful.
I agree with you.
This is, however, largely independent of the 'mandatory' QoS parameter 
idea.

Ciao
Hannes