Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

From: [email-masked]
Date: Mon, 24 Oct 2005 12:23:00 +0300

Georgios,

Do you feel that this is now resolved?  It looks like you and Jerry
have come to an agreement.

John 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Georgios Karagiannis
>Sent: 22 October, 2005 09:58
>To: [email-masked]; [email-masked]
>Cc: Ash, Gerald R (Jerry), ALABS
>Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
>
>
>Hi Jerry
>
>Please see in line!
>
>On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" <[email-masked]> wrote:
>
>>Hi Georgios,
>>
>>Thanks for your detailed example, I think this is a good way 
>to resolve 
>>the issue.
>>
>>> I see that this discussion does not lead anywhere!
>>> Maybe is a good idea to have a lot of discussions in Vancouver 
>>> related to this issue!
>>
>>OK, but let's continue on the list, and see if we can make progress.
>>
>>> Regarding the packet classifier used in the QoS-NSLP, the packet 
>>> classifier should know what kind of filtering should use on 
>the user 
>>> data packets. This is because the created QoS-NSLP (RMF) 
>reservation 
>>> states (not the QoS-NSLP operational states) have to be associated 
>>> with the user data packets passing through the node. 
>Otherwise no QoS 
>>> support can be provided.
>>>
>>> For example:
>>> *  in a Intserv based model, the flow ID will be used to filter the 
>>> user data packets 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:
>>> For this case consider the following:
>>> two QoS models, say QoS model A (that goes end-to-end) and 
>QoS model 
>>> B (that goes locally: edge-to-edge) are used for the same 
>session on 
>>> an end to end path.
>>> The QNE that activates the signaling related to QoS model A 
>generates 
>>> a RESERVE and is including the QSPEC (A) and it is also 
>including the 
>>> type of the packet classifier used (packet classifier (A), say flow 
>>> ID.
>>
>>So the QNE gets the packet_classifier information from where? 
> It seems 
>>it still has to be configured according to the QoS model A 
>that the QNE 
>>is using, right?
>
>Georgios: Yes, you are right, it has to be configured 
>according to the QoS model A, that QNE is using
>
>
>>> All the intermediate nodes that use QoS model (A) will have to use 
>>> QSPEC (A) and the packet classifier (A).
>>> On the end-to-end path the same session (and RESERVE
>>> message) passes through a local QoS model, say QoS model B.
>>> In this case the QNE at the edge of the domain that 
>supports the QoS 
>>> model B, will have to stack its QSPEC (B) on top of QSPEC 
>(A). At the 
>>> same time this QNE will have to include the packet classifier (B), 
>>> information related to QoS model B, say combination of IP source 
>>> address and DSCP, in the RESERVE message, in such a way that packet 
>>> classifier
>>> (A) is not destroyed.
>>
>>Same question the QNE gets the packet_classifier information 
>from where?
>>It seems it still has to be configured according to the QoS model B 
>>that the QNE is using, right?
>
>Georgios: Yes, you are right, it has to be configured 
>according to the QoS model B, that QNE is using
>
>>> All the intermediate nodes that use QoS model B will have to use 
>>> QSPEC (B) and packet classifier (B).  The QNE located at the other 
>>> edge of the domain that supports the QoS model B,  will have to 
>>> remove QSPEC (B) and the packet classifier
>>> (B) from the RESERVE message.
>>>
>>> As you can see the packet classifier information and the QSPEC are 
>>> very much dependent to each other.  Thus there is a one to one 
>>> matching between the packet classifier and the QSPEC.
>>
>>So each QOSM I-D needs to specify what packet_classifier it will use?
>
>
>Georgios: Yes, you are right, each QoSM I-D nees to specify 
>what packet classifier it will use!
>
>
>>> This means that the NSIS protocol suite needs to support the 
>>> following functionalities:
>>>   * packet classifier (B) information should not destroy the packet 
>>> classifier (A) information
>>>   * The packet classifier, say packet classifier (A), 
>associated with 
>>> a QSPEC, say QSPEC (A),  must only be used in the domains that are 
>>> using QSPEC (A).
>>>   * If a QoS model does not recognize a QSPEC, say QSPEC 
>(A) then it 
>>> should not do anything with its associated packet classifier, say 
>>> packet classifier (A).
>>>
>>> If the packet classifier information will be included in the QSPEC, 
>>> then all the above functionalities are already provided!
>>
>>Let's see if others agree with this?
>>
>>Thanks,
>>Regards,
>>Jerry
>
>Best Regards,
>Georgios
>
>_______________________________________________
>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: Mon, 24 Oct 2005 11:43:25 +0200

Hi John

I am not sure what was the conclusion?
Jerry do you agree to include the Packet classifier in the QSPEC?

Best Regards,
Georgios