Bug 897 - [PATCH] API and functionality for marking TOS bytes in packets
[PATCH] API and functionality for marking TOS bytes in packets
Status: PATCH PENDING
Product: ns-3
Classification: Unclassified
Component: internet
pre-release
All All
: P5 normal
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-27 03:14 EDT by Antti Mäkelä
Modified: 2016-03-30 19:33 EDT (History)
1 user (show)

See Also:


Attachments
Marking API for Ipv4. (6.44 KB, patch)
2010-04-27 03:14 EDT, Antti Mäkelä
Details | Diff
Example code on how to use marking. (5.00 KB, text/plain)
2010-04-27 03:15 EDT, Antti Mäkelä
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antti Mäkelä 2010-04-27 03:14:51 EDT
Created attachment 849 [details]
Marking API for Ipv4. 

See http://groups.google.com/group/ns-3-users/msg/5c4d148ad229470a

Patch attached that allows you to perform packet marking for incoming packets, in similar style to class-maps in routers. The API requires you to specify incoming IP Prefix and intended marking pattern (TOS byte), and allows you to specify transport protocol, TCP/UDP src/dst ports, and incoming NetDevice.

Example is a modified static-routing-example, where now the middle node also sets the packets to EF diffserv field.

My intended usage is that this can be used for queuing purposes. I'm intending to modify PointToPointNetDevice so that it has a strict priority queue where packets marked with EF Diffserv codepoint are sent first, however, this also opens door to anyone who wishes to do other types of class-based queues (e.g. CBWFQ).
Comment 1 Antti Mäkelä 2010-04-27 03:15:41 EDT
Created attachment 850 [details]
Example code on how to use marking.

Check the pcap outputs for the center node.
Comment 2 Tom Henderson 2010-06-03 02:11:42 EDT
Sorry for the tardy review.  I think it is useful but I wonder whether it is not general enough (since it is limited to the input interface in a forwarding situation only) and will conflict with other API whenever someone gets around to finishing off the netfilter support:
http://code.nsnam.org/adrian/ns-3-netfilter/
Comment 3 Antti Mäkelä 2010-06-10 04:18:17 EDT
(In reply to comment #2)
> Sorry for the tardy review.  I think it is useful but I wonder whether it is
> not general enough (since it is limited to the input interface in a forwarding
> situation only) and will conflict with other API whenever someone gets around
> to finishing off the netfilter support:
> http://code.nsnam.org/adrian/ns-3-netfilter/

  Ok - well, this is something that I sort of needed "right now" and thought others might find it beneficial as well. If Netfilter provides better functionality (when it's finished) then great :)
Comment 4 Tom Henderson 2016-03-30 19:33:50 EDT
need to consider this again in context of new traffic control module