Interested in {Create an in-kernel API for "packet classes"}

["Indradip Ghosh" <indraghosh2k%gmail.com@localhost>]

Hello Mentors,
This is Indradip, a Grad student at University of Texas at Arlington.
 I am interested to work on the project {Create an in-kernel API for
"packet classes"} .
My proposal is as follows:


Project Goal:

To create an in-kernel API for registering "packet classes" and for
labeling packets
with their class, for special treatment by traffic shapers (ALTQ) and
by network
interface drivers. Such an approach would entitle network devices support varies
 class of service (CoS) based on pre-determined packet transmission priority.


Approach

       (a) PF Packet Filter (PF) is a software program for
manipulating actions on packets being
       transmitted and received by the NetBSD kernel. PF uses a
configuration file (pf.conf(5))
        for reading in the rules that it needs to apply to the network packets.

       Among its many abilities, PF allows a packet to be tagged or
marked based on the input
       ruleset. Additionally, tags are sticky; implying once a packet
is tagged, the tag can
        only be replaced by a subsequent ruleset but can never be
removed. Thus, the flow of
       packets inside the kernel can be represented as:

       apps_data -> kernel packet -> { PF rules -> tagged packets ->
Actions} -> packets (!dropped)

       (b) However, as clear from the above action, the meaning of the
tag is lost as soon the packet
           exits the PF environment. Thus, PF has no knowledge of the
device driver queue capabilities.
           The only exception is the ALTQ implementation which is
integrated with the PF subsystem.
            This allows the PF to implement various interface queuing policies.

       (c)  One way to handle such 'lost information' is to translate
PF tags to languages understood
            by the device driver. The glue for such an approach is the
packet class framework (PCF) being
             proposed in this project.

       (d) (i) Packet Class Framework (PCF): The object of PCF is to
mark packets with tokens as they leave the
           PF subsystem. Tokens are the driver capabilities that are
registered during driver_init ().
            For example, an ethernet NIC with high and low-priority
transmit rings may register
           classes called 'hipri'(2) and 'lopri' (1). These will
generate tokens t0 and t1 corresponding to
            'hipri' and 'lopri'.

           Note that these tokens are predefined data structure that
the driver simply
           needs to instantiate.
                     typedef struct all_tokens {
                                char *drivername; // filled by the driver
                               char *interface; // filled by the kernel
                               struct token driver_token; // list of
all tokens with priority
                        }
             (ii) Once the PCF knows the token names and their
corresponding priority, it needs to
                   match these with the PC tags. Note that tags are
defined based on rulesets.
                    However, there is a catch. Since the tokens are
driver specific, there appers to be
                   standard way of defining the tag-token matching grammar.

             (iii) To solve this dilemma, whenever the deriver
initializes, the PCF will write the
                     tokens with priorities under /dev/pcf/<if_name>.
These tokens must be used in the
                    ruleset of PF.

             (iv) Since packets generated from the kernel are mbuf
structures, packets matching the
                     rulesets will have the tokenens inserted in the
"token" field of the mbuf. This token
                    field is new and will enable the driver to
associate priority with the token type.

Please let me know if you have some clarifications/ comments/
suggestions in this respect and would
greatly appreciate if you could throw light on any issue that I have
failed to address.


Best Regards,
 Indradip.