Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP

From: "Kappler, Cornelia" <[email-masked]>
Date: Tue, 11 Oct 2005 11:42:12 +0200

Hi Georgios, 

if indeed the packet classifier is QSPEC / QoS Model dependent, and we
would need stacked packet classifiers as well as stacked QSPECs it would
make sense to include it in the QSPEC.

However I dont understand why you would use separate packet classfiers
for stacked QSPECs (one of them e.g. e2e QSPEC, the other a
domain-specific RMD QSPEC). The packet classfier specifies what packets
receive the treatment described in the QSPEC. I'd rather expect that for
a given QoS NSLP message, the packets being singled out for treatment
are always the same (no matter what QoS Model is used to reserve
resources). 

Can you make your example more concrete?

Cornelia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Georgios Karagiannis
> Sent: Montag, 10. Oktober 2005 13:28
> To: [email-masked]; [email-masked]; 
> Tschofenig, Hannes; [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP
> 
> 
> Hi John
> 
> I do not have any problem on including this object in the QSPEC.
> 
> Please note that the packet classifier functionality is strict
> associated with a QoS model. A PACKET_CLASSIFIER object 
> specifies which
> filter should be used by the packet classifier functionlaity on
> filtering the user data packets.
> Suppose now that for the same session two qos models are 
> used, one that
> goes end-to-end and the other one that goes edge to edge within a
> domain. Note that this is the case when stacking of QSPEC's is used.
> If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter
> information should this object contain, the filter 
> information required
> by the end-to-end QoS model or the edge-to-edge QoS model?
> 
> In this case this problem can be solved by making the 
> PACKET_CLASSIFIER 
> object in  the
> stackable!
> Do we want this?
> 
> Another solution is to introduce the PACKET_CLASSIFIER object 
> into the 
> QSPEC.
> 
> Best regards,
> Georgios
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, October 10, 2005 12:46 PM
> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP
> 
> 
> > whether this data should be in the qos-nslp or qspec is less
> > clear to me. the concept in my head has always been that the
> > qos-nslp carried everything about *what* resource reservation
> > action you wanted to carry out, and the qspec was about how
> > much "stuff" you actually wanted to reserve. the packet classifier
> > needs to be given in every message about a transaction, whereas
> > the "how much" information only in some; and the classifier can
> > probably be universal, whereas the qspec need not be. I don't
> > see why having it in the qos-nslp is hard.
> >
> > This is where I thought we left it after the interim 
> meeting. I guess
> > if we remove it, I'd like to have some more reasoning behind the
> > removal.
> >
> > John
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 11 Oct 2005 11:54:57 +0200

Hi Cornelia

Please see in line!

----- Original Message ----- 
From: "Kappler, Cornelia" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 11, 2005 11:42 AM
Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP

> receive the treatment described in the QSPEC.

Georgios: Please note that this does not apply to RMD.
Regarding the packet classifier, the packet classifier should know what kind
of filtering should use on the user data packets.
For example:
*  in a Intserv based model, the flow ID will be used to filter the user
data packest and associate them with the
Intserv based RMF reservation state
* in another QoS model, the combination of IP source address and DSCP might 
be
used to filter the user data
packets and associate them with the RMF reservation state

The packet classifier can get this knowledge by:
 *  local policy, configuring the node to associate the RMF reservation
state with all user data packets that are filtered
based on a predefined and configured rule
* using signaling, where the QNE that activates the signaling related to a
QoS model, for example QoS model A,
and if needed stacks a QSPEC (for QoS model A,
is also including the type of the filter that all QNE's using the QoS model
A, will have to use!

> I'd rather expect that for

Georgios: The filtering/packet classification of the user data packets
depends on the QoS model used, see above!
When for the same session, a e2e QoS model is used in combination with a
local QoS model,
that use stacking of QSPECs, a problem will ocuur
if the PACKET_CLASSIFIER will either not be stacked or included in the QSPEC
(it this way relating each QSPEC to one PACKET CLASSIFIER).

Best regards,
Georgios