Bug 897

Summary:	[PATCH] API and functionality for marking TOS bytes in packets
Product:	ns-3	Reporter:	Antti Mäkelä <antti.makela>
Component:	internet	Assignee:	Tommaso Pecorella <tommaso.pecorella>
Status:	PATCH PENDING ---
Severity:	normal	CC:	tomh
Priority:	P5
Version:	pre-release
Hardware:	All
OS:	All
Attachments:	Marking API for Ipv4. Example code on how to use marking.

Description Antti Mäkelä 2010-04-27 03:14:51 UTC

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 UTC

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 UTC

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 UTC

(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 UTC

need to consider this again in context of new traffic control module