Indradip Ghosh
2008-03-31 10:04:57 UTC
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.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
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.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de