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

From: "Cheng Hong" <[email-masked]>
Date: Wed, 26 Oct 2005 16:38:30 +0800

Hi Georgios,

Please see some comments below:

<snip>
> >
> > This would be an easy way to address the NAT issue. We may 
> also need 
> > to identify how to indicate that "one or more parameters" 
> to be used 
> > for the packet classification. Maybe that is what the 
> > PACKET_CLASSIFIER is meant for.
> 
> Georgios: This will have to be defined by the used QoS model, 
> and should not be signaled.
> If a QoS model needs to use other parameters then it will be 
> able to configure them!
> This is up to the QoS model.

You are right that the QoS Model needs to define what should to be
signaled. The concern is that what the QoS Model defined may not be able
to be signaled by using the MRI only. The QoS Model can define a format,
no the contents, because the actual packet classificaiton information
(defined within a QoS Model) could be affected by the operation. As what
we discussed earlier, for example, a QoS Model could define that a MF
classifier is needed, however, it cannot predict that whether the port
number should be wildcarded or a specific port should be used. Whether
to use the port number (or multiple port number) still needs to be
signaled over between QNEs (by using something else than MRI).  

<snip>
> > My feeling is that we at least need to allow some extra 
> information to 
> > be included in the QoS-NSLP to complement the MRI for the packet 
> > classification. So, how about changing the sentence to:
> >
> >> "The QOS-NSLP nodes SHOULD use one or more parameters of 
> the MRI, as 
> >> indicated by PACKET_CLASSIFIER, for packet
> > classification.
> >> When PACKET_CLASSIFIER indicates an additional packet 
> classification
> > object included
> >> in QoS-NSLP, the additional object should be used for packet
> > classification."
> 
> Georgios: The stacking problems will not allow to just use a 
> PACKET CLASSIFIER QoS-NSLP object. You have either to 
> generate a stacked PACKET_CLASSIFIER QOS-NSLP object or you 
> have to included in the QSPEC.
> But as I mentioned above, this information does not have to 
> be signaled.

Yes. If the QSPEC stacking is to be supported, the object has to be
stackable also, as we discussed before. Maybe a simple way out of this
is to limit the stackable option of the QSPEC (disallow that), if we
want to avoid the problem. Even if we limit the information to the MRI,
we still may face the problem for the stackable issue on MRI. (please
see comments below regarding the stackable MRI issue)  

> > As for the NAT traversal problem, I think it would not be 
> an issue if 
> > we can make the indicator for this additional object and the object 
> > itself common for all the NSLPs (as a common function of all the 
> > NSLP). In this case, the NAT doesn't need to be specific 
> NSLP aware to 
> > do the update of the object (same as treating the MRI). So far, I 
> > think this additional packet classification information is 
> useful for 
> > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed 
> metering-NSLP.
> 
> Georgios: But this solution will only work if we mandate that 
> the NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc..
> I think we do not want to impose such requirements!

If every NSLP has the same format, the NAT doesn't need to
understand/know which NSLP is that. It only process the common formated
information element for the packet_classifier if it is present. (well,
that may require an indicator for its presence be placed in the common
header, not tied to message type)

> > For the stackable QSPEC issue raised by Georgios earlier in this 
> > thread, I am not sure how it could be solved by limiting the packet 
> > classification information to the MRI.
> 
> Georgios: It can be solved since the GIST should update the 
> MRI, if the GIST session traverses a NATP that modifies the 
> source/destination port and addresses, then GIST  should 
> modify ther MRI.
> All the NSLPs are using the MRI that is provided by GIST. In 
> this case the described problem by you will be solved.

Please note that this is not about the NAT issue. It is on the stacking
support of the QSPEC you mentioned earlier:

">   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.
>   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 recognise a QSPEC, say QSPEC (A) 
> then it should not do
>     anything with its associated packet classifier, say 
> packet classifier (A).
"

So in this case, if the MRI is the sole source of information for the
packet_classifier, does it also needs to be stackable?

cheers

Cheng Hong

> > the packet classification information for a stacked QSPEC (which is 
> > different from the current MRI), the MRI itself also needs to be 
> > stackable (if it is the sole source of packet classification 
> > information).
> 
> Georgios: No, please see my comment above!
> 
> Best Regards,
> Georgios
> 
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Georgios Karagiannis
> >> Sent: Wednesday, October 26, 2005 12:25 AM
> >> To: Andrew McDonald
> >> Cc: [email-masked]; [email-masked]
> >> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> >>
> >> Hi Andrew
> >>
> >> Please see in line!
> >>
> >> >> Georgios: agree, but in the case of RSVP aggregation 
> the used user 
> >> >> plane is the same as the user plane used by the end to end
> >> session,
> >> >> but this user plane uses different packet classifiers in the 
> >> >> different end to end path locations!
> >> >> The described  case in the thread allows a higher degree of 
> >> >> modularity (i.e., since this is one of the main goals of NSIS).
> >> >
> >> > The different packet classifiers may be a sign that we
> >> should be using
> >> > a different signalling session.
> >> >
> >> > If we take RMD as an example, the per domain (i.e. end-to-end) 
> >> > reservation and the per hop (i.e. aggregate-related)
> >> reservation are
> >> > based on different subsets of information in the MRI, and
> >> so require
> >> > different PACKET_CLASSIFIERs. The end-to-end signalling performs 
> >> > per-microflow reservations based on something like the 
> 5-tuple. The 
> >> > aggregate uses a packet classifier which is just the DSCP.
> >> >
> >> > However, RMD (looking at, for example, figure 3 in the RMD
> >> draft) uses
> >> > separate signalling sessions for its 'per domain' and 'per hop'
> >> > reservations, so only a single PACKET_CLASSIFIER is 
> needed for each 
> >> > session.
> >> >
> >> > Allowing multiple classifiers seems possible, but does look like 
> >> > unnecessary complexity.
> >>
> >> Georgios: Exactly this discussion is not related to the 
> RMD concept!
> >>
> >>
> >> I think that the easier solution will just be to have a 
> sentence in 
> >> the QOS-NSLP draft which says:
> >>
> >> "The QOS-NSLP nodes SHOULD use one or more parameters 
> included in the 
> >> MRI for packet classification."
> >>
> >> In this way we will also allow nodes to use other types of 
> parameters 
> >> for packet classification, by e.g., using local node configuration.
> >>
> >> Please note that in this way the packet classification will work 
> >> fine, it will be simple and it will solve the NAT translation 
> >> problems mentioned by Cheng!
> >>
> >> Please note that something similar is proposed in the 
> NAT./Firewall 
> >> NSLP draft!
> >> Hannes also proposed the above the above solution in one of first 
> >> e-mails relatted to this thread!
> >>
> >> 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
> >>
> >
> >
> > _______________________________________________
> > 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: Wed, 26 Oct 2005 11:09:17 +0200

Hi Cheng

Please see in line!

----- Original Message ----- 
From: "Cheng Hong" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>; "Andrew McDonald" 
<[email-masked]>
Cc: <[email-masked]>; "Takako Sanda" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, October 26, 2005 10:38 AM
Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

> signaled over between QNEs (by using something else than MRI).

Georgios: Why?
A QoS model can configure locally a node to use the MF classifier for packet 
classification.
Another case will be that the QOS model will configure the edge of the
QoS model to use the MF classifier and that then this edge will signal this 
information to all
intermediary nodes (that are using the same QoS model) to use this 
information for packet classification.
In both approaches the QoS model has to configure that!

> see comments below regarding the stackable MRI issue)

Georgios: Well I do not thing that this is the right solution.
I do not understand why you think that stacking is needed.

We do not need to stack the MRI. Each QoS model will choose
the parameters from ther MRI!

> header, not tied to message type)

Georgios: Not sure if this can be applied.
The NATP has to recognise all types of NSLSP messages in order to do that.
Thus it should be all-NSLP aware.

> support of the QSPEC you mentioned earlier:

Georgios: Well each QoS model will choose the required parameters from the 
MRI.
Thus QoS model A will choose some parameters from MRI and QoS model B will 
choose
other parameters from the same MRI. Thus MRI does not need to be stackable!

Best regards,
Georgios