Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Oct 2005 05:45:06 -0500

Hi Georgios, All,

> From the discussion that we have had in the NSIS mailing list, one can
> deduce that the PACKET_CLASSIFIER object cannot be carried as a pure
> QOS-NSLP object. The reason is that this will not work when QSPEC
> stacking is used.
> There are two solutions that one can apply:
> * Local configuration by each node, where the filters will be
> pre-configured by each QoS model
> 
> * signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter!

There is another solution.  If separate packet_classifier's are needed
for each of 2 QSPECs, then the packet-classifiers can be stacked in
QoS-NSLP just as we agreed that separate QSPECs (and their lengths) can
be stacked in QoS-NSLP.

(BTW, it doesn't appear that there is consensus that separate
classifiers would be needed for 2 QSPECs, however.)
 
> From what I have understood, most of the participants in the 
> discussion would prefer the signaling using QSPEC solution!
>
> Is this accepted by the NSIS WG?

I re-read the thread and it appears that Robert, John, Cornelia, and
others support keeping the packet_classifier in QoS-NSLP.  Cheng Hong
also favored to put the packet_classifier in QoS-NSLP
http://www1.ietf.org/mail-archive/web/nsis/current/msg05481.html.  He
raised a good point about a QNE not supporting a particular QOSM, if so,
it may not be able to interpret the packet_classifier.  The proposal to
move the packet_classifier to the QSPEC also seems to contradict the
guidance from the interim meeting.

IMO I don't see why packet_classifier can't be kept in QoS-NSLP as
others have also suggested.

Thanks,
Regards,
Jerry

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 20 Oct 2005 07:09:50 +0200 (MEST)

Hi Jerry

Please see in line!

>QoS-NSLP just as we agreed that separate QSPECs (and their lengths) can

Georgios: Yes, I agree that this solution can also be used. But if we
will use this solution then
all the QoS-NSLP stacking functionality used for QSPEC processing will
also
have to be used
for Packet classifier processing! This is not efficient, increases the
proibability of errors and the complexity of the
QoS-NSLP protocol
If the packet classifier will be included in the QSPEC then neither the
complexity of the QOS-NSLP protocol nor the complexity of the QSPEC
functionality is increased.
When we will use one packet classifier parameter per QSPEC, then this
parameter is just another QSPEC parameter.

>classifiers would be needed for 2 QSPECs, however.)

Georgios: Well, I thought that there is a consensus that there is a
problem when one session will have to provide signaling to at least two
QoS models in an end to end path, where one of these QoS models goes end
to end and the other is applied locally.
We cannot deny the problem, because otherwise, the NSIS solution of
stacking two QSPECS will be useless!

>others support keeping the packet_classifier in QoS-NSLP.  

Georgios: Well, somehow they probably do not want to continue the
discussion!
We cannot deny the problem now and realize after one year that indeed we
had to solve the problem one year earlier!

Please note that Jukka is very much in favour of moving the packet
classifier parameter into QSPEC!

> Cheng Hong
>it may not be able to interpret the packet_classifier.  

Georgios: But this is an error situation that must not occur! This is
because
each Qos model MUST be able to use a different filter/packet classifier
than some other QoS model, in an end to end path.
Please understand that filtering and packet classification is a QOS model
dependend functionality.

Some other arguments against the proposal of including the packet
classifier parameter into the QSPEC, where related to firewall traversal
issues!
If we include the packet classifier parameter into the QSPEC then this
problem will not occur, since the packet classifier parameter will just
be another parameter of the QSPEC object!

Thus based on this, the packet classifier should be included in the QSPEC.

> The proposal to

Georgios: During the NSIS interim meeting no one brought this problem on
the table! We cannot deny the problem now and realize after one year
that indeed we had to solve the problem one year earlier!

>others have also suggested.

Georgios: please see above!