+The component ``tos/lib/net/ctp/CtpForwardingEngineP`` implements the
+forwarding engine. It has five repsonsibilities:
+
+ 1) Transmitting packets to the next hop, retransmitting when necessary, and
+ passing acknowledgment based information to the link estimator
+ 2) Deciding *when* to transmit packets to the next hop
+ 3) Detecting routing inconsistencies and informing the routing engine
+ 4) Maintaining a queue of packets to transmit, which are a mix of locally
+ generated and forwarded packets
+ 5) Detecting single-hop transmission duplicates caused by lost acknowledgments
+
+The four key functions of the forwading engine are packet reception
+(``SubReceive.receive()``), packet forwarding (``forward()``), packet
+transmission (``sendTask()``) and deciding what to do after a packet
+transmission (``SubSend.sendDone()``).
+
+The receive function decides whether or not the node should forward a
+packet. It checks for duplicates using a small cache of recently received
+packets. If it decides a packet is not a duplicate, it calls the
+forwading function.
+
+The forwarding function formats the packet for forwarding. It checks the
+received packet to see if there is possibly a loop in the network.
+It checks if there is space in the transmission queue.
+If there is no space, it drops the packet and sets the C bit. If the
+transmission queue was empty, then it posts the send task.
+
+The send task examines the packet at the head of the transmission
+queue, formats it for the next hop (requests the route from the
+routing layer, etc.), and submits it to the AM layer.
+
+When the send completes, sendDone examines the packet to see the result.
+If the packet was acknowledged, it pulls the packet off the transmission
+queue. If the packet was locally generated, it signals sendDone() to the
+client above. If it was forwarded, it returns the packet to the forwarding
+message pool. If there are packets remaining in the queue (e.g., the
+packet was not acknowledged), it starts a randomized timer that reposts
+this task. This timer essentially rate limits CTP so that it does not
+stream packets as quickly as possible, in order to prevent self-collisions
+along the path.
+
+7. Citations
+====================================================================
+
+| Rodrigo Fonseca
+| 473 Soda Hall
+| Berkeley, CA 94720-1776
+|
+| phone - +1 510 642-8919
+| email - rfonseca@cs.berkeley.edu
+|
+|
+| Omprakash Gnawali
+| Ronald Tutor Hall (RTH) 418
+| 3710 S. McClintock Avenue
+| Los Angeles, CA 90089
+|
+| phone - +1 213 821-5627
+| email - gnawali@usc.edu
+|
+|
+| Kyle Jamieson
+| The Stata Center
+| 32 Vassar St.
+| Cambridge, MA 02139
+|
+| email - jamieson@csail.mit.edu
+|
+|
+| Philip Levis
+| 358 Gates Hall
+| Computer Science Laboratory
+| Stanford University
+| Stanford, CA 94305
+|
+| phone - +1 650 725 9046
+| email - pal@cs.stanford.edu
+
+8. Citations
+====================================================================
+
+.. [1] TEP 124: Link Estimation Extension Protocol
+.. [2] Philip Levis, Neil Patel, David Culler and Scott Shenker. "A
+ Self-Regulating Algorithm for Code Maintenance and Propagation
+ in Wireless Sensor Networks." In Proceedings of the First USENIX
+ Conference on Networked Systems Design and Implementation (NSDI), 2004.
+
+