Subject: QDDIM: Preamble marking

From: "Robert Moore" <[email-masked]>
Date: Fri, 18 May 2001 12:38:59 -0400

In QDDIM-03, there is an uneasy combination of two
partial solutions to address the problem of how to
identify flows on a datapath.  In this note I propose
that we complete the PreambleMarker approach, and
remove the remaining traces of the approach based on
the NextService.TrafficClass property.

The problem we're looking to solve can be summarized
as follows:  we need ways to both (1) capture and
(2) use information about intermediate results, like
InProfile vs. OutOfProfile for a meter.  There's also
another requirement that has been brought up a few times,
that we need to decide whether we're going to try to
address in QDDIM: information that's captured on an
ingress interface, prior to a packet's trip across the
routing core, needs to be available for use when the
packet reaches an egress interface.  As I read [DSMODEL],
they decided not to address this requirement.  But I
think we've been leaning towards saying that we will
address it in QDDIM.

This is important because (I think) this additional
requirement forces us down the PreambleMarker /
PreambleFilter path, as opposed to the NextService.
TrafficClass path.  The reason is that the chain of
NextService associations is always broken by the
routing core, and must start over with the first
ConditioningService on an egress interface.  The
packet preamble serves as the vehicle for getting the
information from the ingress side to the egress side.

So here's my proposal for QDDIM:

1. We follow the basic [DSMODEL] approach, which says
   that if you need to re-split traffic streams that
   have been merged together, you must insert a new
   Classifier.

2. We remove TrafficClass entirely from NextService,
   so that the only keys for the association are the
   two references.  This makes it very easy to draw
   instance diagrams, since there's always at most
   one NextService instance between any two
   ConditioningServices.

3. On the theory that we want to start small, we add
   *one* capability beyond the existing packet-
   classification criteria: the ability to capture and
   use information about what happened to a packet at
   a particular meter.  So the "capture" part of the
   picture looks like this:

      +---------+
      | Meter-A |
   a  |         | b      d
  --->|      In-|---PM-1--->
      |         | c      e
      |     Out-|---PM-2--->
      +---------+

   Each of the five instances of NextService (actually,
   NextServiceAfterMeter in the case of b and c) is
   uniquely identified by its two reference properties.
   PreambleMarker PM-1 adds the following information to
   the packet preamble: (Meter-A, In).  I don't think
   we need to specify the format of this information in
   the model -- just that it's a two-element structure
   that identifies a meter and a result.  Similarly,
   PreambleMarker PM-2 adds (Meter-A, Out) to the
   preambles of packets that come through it.

4. For the "use" part, we need a new subclass of
   FilterEntryBase that matches on these
   (<meter>, <result>) structures in a packet's
   preamble.  To simplify the case where there's just
   a single level of metering in a box, but different
   individual meters on each ingress interface, I think
   we want to allow a wildcard "any" for the <meter>
   part of one of these filters.  With this wildcard,
   an administrator could then specify a Classifier to
   select all packets that were found to be InProfile
   by their respective meters, without having to name
   each meter individually in a separate
   ClassifierElement.

5. An implication of 1 and 2 is that when we're dealing
   with microflows, we'll often need to reclassify
   after merging the flows:

            +---------+               +----+
            | Meter-A |               |CL-1|--GOLD----->
   GOLD---->|         |          +--->|    |--SILVER--->
   SILVER-->|      In-|---PM-1---+    |    |--BRONZE--->
   BRONZE-->|         |               +----+
            |     Out-|---PM-2---+
            +---------+          |    +----+
                                 |    |CL-2|--GOLD----->
                                 +--->|    |--SILVER--->
                                      |    |--BRONZE--->
                                      +----+

I think that this proposal is one that (a) solves our
particular requirement of preserving metering results
across the routing core (as well as along the datapath
on a particular ingress or egress interface) and (b) is
small enough that we can add, and add correctly, in the
next version of QDDIM.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]