Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 20 Oct 2005 11:57:37 -0500

Hi All,
 
RE Robert's and John's postings on this thread:
http://www1.ietf.org/mail-archive/web/nsis/current/msg05479.html
http://www1.ietf.org/mail-archive/web/nsis/current/msg05486.html

"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."

I think this is the right way to think about where to put the
packet_classifier.  I agree with John and Robert that the
packet_classifier fits more into qos-nslp and "what" resource
reservation action is signaled rather than "how much stuff" is signaled
using QSPEC.

In particular, according to the NSIS framework
http://ietf.org/rfc/rfc4080.txt:

"A flow is defined by a packet classifier (in the simplest cases, just
the destination address and topological origin are needed).  In general
we assume that when discussing only the data flow path, we only need to
consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent)."

It seems to me that since packet_classifier identifies the flow, that
information relates to the "what" you are signaling (i.e., identifying
the flow) and not to the "how much stuff" (bandwidth, etc.) associated
with the flow.  How does an RMF identify a flow to populate the
packet_classifier?

Also, there are complexities in changing packet_classifiers for a flow
identified in the NSIS framework.  Again quoting from the NSIS
framework:

"However, for some more complex scenarios (especially mobility and
multihoming related ones; see [1] and the mobility discussion of [5]),
it is desirable to update the flow:session mapping during the session
lifetime.  For example, a new flow can be added, and the old one deleted
(and maybe in that order, for a 'make-before-break' handover),
effectively transferring the network control state between data flows to
keep it associated with the same session.  Such updates are best managed
by the end systems (generally, systems that understand the flow:session
mapping and are aware of the packet classifier change).  To enable this,
it must be possible to relate signaling messages to sessions as well as
to data flows.  A session identifier (Section 4.6.2) is one component of
the solution.
...
Note that the crossover router discovery may involve end-to-end
signaling exchanges (especially for flows towards the mobile or
multihomed node), which raises a latency concern.  On the other hand,
end-to-end signaling will have been necessary in any case, at the
application level not only to communicate changed addresses, but also to
update packet classifiers along the path.  It is a matter for further
analysis to decide how these exchanges could be combined or carried out
in parallel.

On the shared part of the path, signaling is needed at least to update
the packet classifiers to include the new flow, although if correlation
with the existing flow is possible it should be possible to bypass any
policy or admission control processing.  State installation on the new
path (and possibly release on the old one are also required.  Which
entity (one of the end hosts or the crossover router) controls all these
procedures depends on which entities are authorized to carry out network
state manipulations, so this is therefore a matter of signaling
application and NSLP design.  The approach may depend on the
sender/receiver orientation of the original signaling (see Section
3.3.1).  In addition, in the mobility case, the old path may no longer
be directly accessible to the mobile node; inter-access-router
communication may be required to release state in these circumstances."

IMO it isn't possible for the RMF to do these functions/manipulations
with the packet_classifier.  If it is possible, please clarify how.

Thanks,
Regards,
Jerry

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

---

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

Hi Jerry

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!

Regarding the packet classifier used in the Qo-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 Qo-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 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 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.
   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.
  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 QSEPC (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.
  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).

If the packet classifier information will be included in the QSPEC, then all 
the above functionalities
are already provided!

Best Regards,
Georgios