diff --git a/.hgignore b/.hgignore index 7db040164..bd6e7ee93 100644 --- a/.hgignore +++ b/.hgignore @@ -8,7 +8,12 @@ ^doc/html ^doc/latex ^doc/ns3-object.txt -^\.lock-wafbuild +^\.lock-waf_darwin_build +^\.lock-waf_linux2_build +^\.lock-waf_cygwin_build +^\.lock-waf_freebsd7_build +^\.lock-waf_freebsd8_build +^\.lock-waf_freebsd9_build ^\.waf ^doc/introspected-doxygen\.h$ .*\.py[co]$ diff --git a/.hgtags b/.hgtags index 8d71042c4..e92d91d48 100644 --- a/.hgtags +++ b/.hgtags @@ -60,3 +60,4 @@ e48ed3aabca6ad71c8c49e4604c0f83345eda6a8 ns-3.11-RC3 9843c12351cb5ceb9613c9db390d94073b713284 ns-3.11 19c9e2b33b4a53f200be80cd49810bdfecf76770 ns-3.12-RC1 167fc2274f53d4d89fdd769e4a7683ad7b6b7157 ns-3.12 +9007193fbb8d18b69a1feb6aec16501dcf138b6f ns-3.13 diff --git a/AUTHORS b/AUTHORS index afda58ee6..320c14d7a 100644 --- a/AUTHORS +++ b/AUTHORS @@ -1,3 +1,4 @@ +Alexander Afanasyev Kirill Andreev (andreev@iitp.ru) Dean Armstrong (deanarm@gmail.com) Nicola Baldo (nbaldo@cttc.es) @@ -6,6 +7,7 @@ Ramon Bauza (monbauza@gmail.com) Mehdi Benamor (mehdi.benamor@telecom-bretagne.eu) Raj Bhattacharjea (raj.b@gatech.edu) Timo Bingmann (timo.bingmann@student.kit.edu) +Julien Boite Elena Borovkova (borokovaes@iitp.ru) Pavel Boyko (boyko@iitp.ru) Dan Broyles (muxman@sbcglobal.net) @@ -25,9 +27,13 @@ Martin Giachino (martin.giachino@gmail.com,giachino@fing.edu.uy) Charline Taibi Guguen (charline.guguen@gmail.com) Tom Goff (tgoff@tgoff.net) David Gross (gdavid.devel@gmail.com) +Daniel Halperin Tom Henderson (tomhend@u.washington.edu) Blake Hurd (naimorai@gmail.com) +ishan Mohamed Amine Ismail (amine.ismail@inria.fr, iamine@udcast.com) +Atishay Jain +Sascha Alexander Jopen Sam Jansen (sam.jansen@gmail.com) Liu Jian (liujatp@gmail.com) Joe Kopena (tjkopena@cs.drexel.edu) @@ -35,12 +41,14 @@ Flavio Kobuta (flaviokubota@gmail.com) Aleksey Kovalenko (kovalenko@iitp.ru) Mathieu Lacage (mathieu.lacage@inria.fr) Emmanuelle Laprise (emmmanuelle.laprise@bluekazoo.ca) +Björn Lichtblau (lichtbla@informatik.hu-berlin.de) Keith Ma (keith.nwsuaf@gmail.com) Federico Maguolo (maguolof@dei.unipd.it) Antti Makela (zarhan@cc.hut.fi) Francesco Malandrino (francesco.malandrino@gmail.com) Fabian Mauchle (f1mauchl@hsr.ch) Andrey Mazo (mazo@iitp.ru) +Vedran Miletić Faker Moatamri (faker.moatamri@inria.fr) Sidharth Nabar (snabar@uw.edu) Hemanth Narra (hemanth@ittc.ku.edu) @@ -48,9 +56,11 @@ Michael Nowatkowski (nowatkom@gmail.com) Duy Nguyen (duy@soe.ucsc.edu) Tommaso Pecorella (tommaso.pecorella@unifi.it) Josh Pelkey (jpelkey@gatech.edu) +Colin Perkins Giuseppe Piro (g.piro@poliba.it) Yana Podkosova (yanapdk@rambler.ru) Guangyu Pei (guangyu.pei@boeing.com) +Andrea Ranieri Bruno Ranieri (Yrrsinn@googlemail.com) Ken Renard (kenneth.renard@arl.army.mil) George F. Riley (riley@ece.gatech.edu) @@ -61,13 +71,17 @@ Florian Schmidt (Florian.Schmidt@cs.rwth-aachen.de) Guillaume Seguin (guillaume.seguin@inria.fr) Kulin Shah (m.kulin@gmail.com) Phillip Sitbon (phillip.sitbon@gmail.com) +Anirudh Sivaraman Ewgenij Starostin (estar@cs.tu-berlin.de) +YunQiang Su Lalith Suresh (suresh.lalith@gmail.com) +Marcos Talau Adrian S. W. Tam (adrian.sw.tam@gmail.com) Hajime Tazaki (tazaki@sfc.wide.ad.jp) Wilson Thong (wilsonwk@ee.cityu.edu.hk) Mauro Tortonesi (mauro.tortonesi@unife.it) Quincy Tse (quincy.tse@gmail.com) +Frederic Urbani (frederic.urbani@inria.fr) Andras Varga (andras@omnetpp.org) Sebastien Vincent (vincent@clarinet.u-strasbg.fr) Guillaume Vu-Brugier (gvubrugier@gmail.com) diff --git a/CHANGES.html b/CHANGES.html index 56489da3c..af79cd803 100644 --- a/CHANGES.html +++ b/CHANGES.html @@ -53,7 +53,7 @@ This has a few changes for users and developers:
  • by default, "build" no longer has a subdirectory debug or optimized. To get different build directories for different build types, you can use -the waf configure -o xxx option, e.g.: +the waf configure -o option, e.g.: 
       ./waf configure -o shared
   ./waf configure --enable-static -o static
@@ -76,7 +76,10 @@ instead of CXXDEFINES
 
 
    New API:
    
 
      
-
    •  In the mobility module, there is a new API MobilityModel::GetRelativeSpeed() returning the relative speed of two objects. Proposed by Jens Mittag.
      • 
+
    •  In the mobility module, there is a new MobilityModel::GetRelativeSpeed() method returning the relative speed of two objects. 
      • 
+
    •  A new Ipv6AddressGenerator class was added to generate sequential
+addresses from a provided base prefix and interfaceId.  It also will detect
+duplicate address assigments. 
      •  
 
    
 
 
    Changes to existing API:
    
@@ -101,6 +104,28 @@ width standards has had a change in capitalization:
 
 
    Changed behavior:
    
 
      
+
    •  TCP bug fixes
+
         
+
      •  Connection retries count is a separate variable with the retries limit, so cloned sockets can reset the count
+
      •  Fix bug on RTO that may halt the data flow
+
      •  Make TCP endpoints always holds the accurate address:port info
+
      •  RST packet is sent on closed sockets
+
      •  Fix congestion window sizing problem upon partial ACK in TcpNewReno
+
      •  Acknowledgement is sent, rather than staying silent, upon arrival of unacceptable packets
+
      •  Advance TcpSocketBase::m_nextTxSequence after RTO
+
      
+
    •  TCP enhancements
+
        
+
      •  Latest RTT value now stored in variable TcpSocketBase::m_lastRtt
+
      •  The list variable TcpL4Protocol::m_sockets now always holds all the created, running TcpSocketBase objects
+
      •  Maximum announced window size now an attribute, ns3::TcpSocketBase::MaxWindowSize
+
      •  TcpHeader now recognizes ECE and CWR flags (c.f. RFC3168)
+
      •  Added TCP option handling call in TcpSocketBase for future extension
+
      •  Data out of range (i.e. outsize acceptable range of receive window) now computed on bytes, not packets
+
      •  TCP moves from time-wait state to closed state after twice the time specified by attribute ns3:TcpSocketBase::MaxSegLifeTime
+
      •  TcpNewReno supports limited transmit (RFC3042) if asserting boolean attribute ns3::TcpNewReno::LimitedTransmit
+
      •  Nagle's algorithm supported. Default off, turn on by calling TcpSocket::SetTcpNoDelay(true)
+
      
 
    
 
 
    
diff --git a/RELEASE_NOTES b/RELEASE_NOTES
index ee570f096..1a4492a9c 100644
--- a/RELEASE_NOTES
+++ b/RELEASE_NOTES
@@ -14,7 +14,27 @@ Release 3.13
 
 Availability
 ------------
-This release is not yet available.
+This release is available from: 
+http://www.nsnam.org/release/ns-allinone-3.13.tar.bz2
+
+Supported platforms
+-------------------
+ns-3.13 has been tested on the following platforms.  Not all features are
+available on all platforms; check the Installation page on the project wiki.
+
+- Ubuntu 11.10 (32 bit) with g++-4.5.2
+- Ubuntu 11.04 (32/64 bit) with g++-4.5.2 
+- Ubuntu 10.04.3 LTS (64 bit) with g++-4.4.3, g++-3.4.6 
+- OS X Lion with g++-4.2.1
+- OS X Snow Leopard with g++-4.2.1 
+- Fedora Core 16 (32/64 bit) with g++-4.6.2
+  --  however, g++-3.4.6 fails on Fedora 16 i686 
+- Fedora Core 14 (64 bit) with g++-4.5.1
+- FreeBSD 9.0-RC1 (AMD64) with g++-4.2.1
+
+New user-visible features
+-------------------------
+- IPv6 address generator with support for duplicate address detection
 
 Bugs fixed
 ----------
@@ -59,21 +79,6 @@ Bugs fixed
  - Corrected compilation behavior in Ubuntu 11.10 due to ldd behavior change
  - Added required PTHREAD dependency to RT library check.
 
-Supported platforms
--------------------
-ns-3.13 has been tested on the following platforms.  Not all features are
-available on all platforms; check the Installation page on the project wiki.
-
-- Ubuntu 11.04 (32/64 bit) with g++-4.5.2 
-- Ubuntu 10.04.3 LTS (64 bit) with g++-4.4.3, g++-3.4.6 
-- OS X Lion with g++-4.2.1
-- OS X Snow Leopard with g++-4.2.1 
-- Fedora Core 14 (64 bit) with g++-4.5.1
-
-New user-visible features
--------------------------
-- IPv6 address generator
-
 Known issues
 ------------
 In general, known issues are tracked on the project tracker available
diff --git a/bindings/python/wscript b/bindings/python/wscript
index e8111eab1..e38aa82d9 100644
--- a/bindings/python/wscript
+++ b/bindings/python/wscript
@@ -38,7 +38,7 @@ def set_pybindgen_pythonpath(env):
 
 
 def options(opt):
-    opt.tool_options('python', ["waf-tools"])
+    opt.tool_options('python')
     opt.add_option('--disable-python',
                    help=("Don't build Python bindings."),
                    action="store_true", default=False,
@@ -91,7 +91,7 @@ def configure(conf):
         conf.env.PYTHON = Options.options.with_python
 
     try:
-        conf.check_tool('python', ["waf-tools"])
+        conf.check_tool('python')
         conf.check_python_version((2,3))
         conf.check_python_headers()
     except Configure.ConfigurationError, ex:
@@ -479,7 +479,7 @@ def build(bld):
         bld.new_task_gen(features='copy',
                          source="ns__init__.py",
                          target='ns/__init__.py')
-        bld.install_as('${PYTHONDIR}/ns/__init__.py', 'ns__init__.py')
+        bld.install_as('${PYTHONARCHDIR}/ns/__init__.py', 'ns__init__.py')
 
 
     # note: the actual build commands for the python bindings are in
diff --git a/doc/doxygen.conf b/doc/doxygen.conf
index f720bbba4..e54a4725b 100644
--- a/doc/doxygen.conf
+++ b/doc/doxygen.conf
@@ -655,7 +655,6 @@ EXAMPLE_PATH           = src/aodv/examples \
                          src/propagation/examples \
                          src/spectrum/examples \
                          src/tap-bridge/examples \
-                         src/template/examples \
                          src/tools/examples \
                          src/topology-read/examples \
                          src/uan/examples \
diff --git a/doc/main.h b/doc/main.h
index 1fc18899d..62ade2048 100644
--- a/doc/main.h
+++ b/doc/main.h
@@ -56,7 +56,6 @@
  *     - spectrum
  *     - stats
  *     - tap-bridge
- *     - template
  *     - test
  *     - tools
  *     - topology-read
@@ -66,7 +65,6 @@
  *     - wifi
  *     - wimax
  *
- *
  */
 /**
  * \namespace ns3
diff --git a/doc/manual/Makefile b/doc/manual/Makefile
index 9931864a5..b6a3760c0 100644
--- a/doc/manual/Makefile
+++ b/doc/manual/Makefile
@@ -11,15 +11,23 @@ IMAGES_EPS = \
 # rescale pdf figures as necessary
 $(FIGURES)/software-organization.pdf_width = 5in
 
-IMAGES_PNG = \
+# Do not delete/clean these png images upon make clean
+IMAGES_PNG_SAVED = \
 	$(FIGURES)/plot-2d.png \
 	$(FIGURES)/plot-2d-with-error-bars.png \
 	$(FIGURES)/plot-3d.png \
+
+IMAGES_PNG_CONVERTED = \
 	${IMAGES_EPS:.eps=.png}
+
+IMAGES_PNG = $(IMAGES_PNG_SAVED) $(IMAGES_PNG_CONVERTED)
+
 IMAGES_PDF = ${IMAGES_EPS:.eps=.pdf}
 
 IMAGES = $(IMAGES_EPS) $(IMAGES_PNG) $(IMAGES_PDF)
 
+IMAGES_TO_CLEAN = $(IMAGES_PNG_CONVERTED) $(IMAGES_PDF) $(IMAGES_EPS)
+
 %.eps : %.dia; $(DIA) -t eps $< -e $@
 %.png : %.dia; $(DIA) -t png $< -e $@
 %.png : %.eps; $(CONVERT) $< $@
@@ -60,7 +68,7 @@ help:
 
 clean:
 	-rm -rf $(BUILDDIR)
-	-rm -rf $(IMAGES)
+	-rm -rf $(IMAGES_TO_CLEAN)
 
 frag: pickle
 	@if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi
@@ -161,3 +169,4 @@ doctest: $(IMAGES)
 	      "results in $(BUILDDIR)/doctest/output.txt."
 
 
+test: $(IMAGES)
diff --git a/doc/manual/source/attributes.rst b/doc/manual/source/attributes.rst
index dd4e00d23..c89c470d6 100644
--- a/doc/manual/source/attributes.rst
+++ b/doc/manual/source/attributes.rst
@@ -1,5 +1,7 @@
 .. include:: replace.txt
 
+.. _Attributes:
+
 Attributes
 ----------
 
@@ -58,7 +60,7 @@ For most basic usage (syntax), treat a smart pointer like a regular pointer:::
 CreateObject
 ++++++++++++
 
-As we discussed above in :ref:`Memory management and class Ptr`, at the
+As we discussed above in :ref:`Memory-management-and-class-Ptr`, at the
 lowest-level API, objects of type :cpp:class:`ns3::Object` are not instantiated
 using ``operator new`` as usual but instead by a templated function called
 :cpp:func:`CreateObject()`.
@@ -412,7 +414,7 @@ determine the required concrete configuration namespaced path.::
 
     Config::Set ("/Names/server/eth0/TxQueue/MaxPackets", UintegerValue (25));
 
-:ref:`Object names` for a fuller treatment of the |ns3| configuration namespace.
+:ref:`Object-names` for a fuller treatment of the |ns3| configuration namespace.
 
 Setting through constructors helper classes
 +++++++++++++++++++++++++++++++++++++++++++
diff --git a/doc/manual/source/new-models.rst b/doc/manual/source/new-models.rst
index f8788f6b2..e2f158344 100644
--- a/doc/manual/source/new-models.rst
+++ b/doc/manual/source/new-models.rst
@@ -249,7 +249,7 @@ use of class Object?
 This is an important design step; whether to use class :cpp:class:`Object` as a
 base class for your new classes.
 
-As described in the chapter on the |ns3| :ref:`Object model`, classes that
+As described in the chapter on the |ns3| :ref:`Object-model`, classes that
 inherit from class :cpp:class:`Object` get special properties:
 
 * the |ns3| type and attribute system (see :ref:`Attributes`)
@@ -370,7 +370,7 @@ certain objects can be created via the object creation framework
 
 The macro ``NS_OBJECT_ENSURE_REGISTERED (classname)`` is needed also once for
 every class that defines a new GetTypeId method, and it does the actual
-registration of the class into the system.  The :ref:`Object model` chapter
+registration of the class into the system.  The :ref:`Object-model` chapter
 discusses this in more detail.
 
 how to include files from elsewhere
diff --git a/doc/manual/source/new-modules.rst b/doc/manual/source/new-modules.rst
index 35a09bd45..2018d32dd 100644
--- a/doc/manual/source/new-modules.rst
+++ b/doc/manual/source/new-modules.rst
@@ -39,59 +39,47 @@ Not all directories will be present in each module.
 Step 2 - Create your new module based on the template module
 ************************************************************
 
-The template module ::
+A python program is provided in the source directory that will create a skeleton for a new module ::
 
-  src/template
+  src/create-module.py
 
-is a skeleton module that shows how modules should be created.
+For the purposes of this discussion we will assume that your new module is called "new-module".  From the ``src`` directory, do the following to create the new module: ::
 
-For the purposes of this discussion we will assume that your new module is called "new-module".  From the top level |ns3| directory, do the following to copy the template module to a new directory with the same name as your new module: ::
+  ./create-module.py new-module
 
-  cp -r src/template src/new-module
+Next, cd into ``new-module``; you will find this directory layout: ::
 
-Now you will need to open the following file in your favorite text editor: ::
+  examples  helper  model  test  wscript
 
-  src/new-module/wscript
-
-and replace all of the occurrences of "template" in this wscript file with the name of your new module, i.e. "new-module" for our assumed module name.
-
-You will also need to specify the |ns3| modules your new module will
-depend on.  Let's assume that "new-module" depends on the internet,
+We next walk through how to customize this module.  All |ns3| modules
+depend on the 'core' module and usually on other modules.  This 
+dependency is specified in the wscript file.  
+Let's assume that 'new-module' depends on the internet,
 mobility, and aodv modules.  Then the call to the function that will
-create this module should look like this when you are done with this
-step: ::
+create this module should look like this before editing: ::
 
-    module = bld.create_ns3_module('new-module', ['internet', 'mobility', 'aodv'])
+  def build(bld):
+      module = bld.create_ns3_module('new-module', ['core'])
 
-As an example, the dependencies for the spectrum module are specified
-in ::
+and after editing: ::
 
-  src/spectrum/wscript
+  def build(bld):
+      module = bld.create_ns3_module('new-module', ['internet', 'mobility', 'aodv'])
 
-with the following function call: ::
+Your module will most likely have model source files.  Initial skeletons (which will compile successfully) are created in ``model/new-module.cc`` and ``model/new-module.h``.  
 
-    module = bld.create_ns3_module('spectrum', ['internet', 'propagation',
-        'applications'])
+If your module will have helper source files, then they will go into the helper/ directory; again, initial skeletons are created in that directory.
 
-If your module will have model source files, then create the following directory where they will go: :: 
+Finally, it is good practice to write tests.  A skeleton test suite and test case is created in the test/ directory.  The below constructor specifies that it will be a unit test named 'new-module':  ::
 
-  mkdir src/new-module/model
+  New-moduleTestSuite::New-moduleTestSuite ()
+    : TestSuite ("new-module", UNIT)
+  {
+    AddTestCase (new New-moduleTestCase1);
+  }
 
-Copy all of your module's model source files to the above directory.
-
-If your module will have helper source files, then create the following directory where they will go: :: 
-
-  mkdir src/new-module/helper
-
-Copy all of your module's helper source files to the above directory.
-
-If your module will have tests, then copy all of your module's test files to the following directory: :: 
-
-  mkdir src/new-module/test
-
-
-Step 3 - Specify your module's source files
-*******************************************
+Step 3 - Adding to your module's source files
+*********************************************
 
 If your new module has model and/or helper source files, then they
 must be specified in your  ::
@@ -139,7 +127,7 @@ with the following function call, module name, and list of header
 files.  Note that the argument for the function new_task_gen() tells
 waf to install this module's headers with the other |ns3| headers: ::
 
-    headers = bld.new_task_gen('ns3header')
+    headers = bld.new_task_gen(features=['ns3header'])
 
     headers.module = 'spectrum'
 
@@ -194,7 +182,7 @@ As an example, the examples for the core module are specified in ::
 
 The core module's C++ examples are specified using the following
 function calls and source file names.  Note that the second argument
-for the function create_ns3_program() is the list of modules that the
+for the function ``create_ns3_program()`` is the list of modules that the
 program being created depends on: ::
 
     obj = bld.create_ns3_program('main-callback', ['core'])
@@ -210,18 +198,16 @@ depends on: ::
 
     bld.register_ns3_script('sample-simulator.py', ['core'])
 
-Step 7 - Specify which of your module's examples should be run
-**************************************************************
+Step 7 - Specify which of your module's examples should be run as tests
+***********************************************************************
 
-If your new module has examples, then you must specify which of them
-should be run in your ::
+The test framework can also be instrumented to run example programs to
+try to catch regressions in the examples.  However, not all examples
+are suitable for regression tests.  A file called ``examples-to-run.py``
+that exists in each module's test directory can control the invocation
+of the examples when the test framework runs.
 
-  src/new-module/test/examples-to-run.py
-
-file by modifying it with your text editor.  These examples are run by
-test.py.
-
-As an example, the examples that are run by test.py for the core module are specified in  ::
+As an example, the examples that are run by ``test.py`` for the core module are specified in  ::
 
   src/core/test/examples-to-run.py
 
@@ -279,47 +265,15 @@ depend on waf configuration variables.  For example, ::
 
     ("realtime-udp-echo.py", "ENABLE_REAL_TIME == False"),
 
+If your new module has examples, then you must specify which of them
+should be run in your ::
 
-Step 8 - Add your module to the list on |ns3| modules
-*****************************************************
+  src/new-module/test/examples-to-run.py
 
-Your new module must be added to the current list of |ns3| modules by modifying the following wscript file with your text editor: ::
+file by modifying it with your text editor.  These examples are run by
+test.py.
 
-  src/wscript
-
-In that file, you will find the following list of modules ::
-
-  all_modules = (
-      'core',
-      'network',
-      'config-store',
-      'internet',
-          .
-          .
-          .
-      'point-to-point-layout',
-      'csma-layout',
-      'template',
-      )
-
-Add your new module's name to the list like this ::
-
-  all_modules = (
-      'core',
-      'network',
-      'config-store',
-      'internet',
-          .
-          .
-          .
-      'point-to-point-layout',
-      'csma-layout',
-      'template',
-      'new-module',
-      )
-
-
-Step 9 - Build and test your new module
+Step 8 - Build and test your new module
 ***************************************
 
 You can now build and test your module as normal: ::
@@ -328,4 +282,4 @@ You can now build and test your module as normal: ::
   ./waf build
   ./test.py
 
-
+and look for your new module's test suite (and example programs, if enabled) in the test output.
diff --git a/doc/manual/source/object-model.rst b/doc/manual/source/object-model.rst
index 29a6d9563..b51559707 100644
--- a/doc/manual/source/object-model.rst
+++ b/doc/manual/source/object-model.rst
@@ -1,5 +1,7 @@
 .. include:: replace.txt
 
+.. _Object-model:
+
 Object model
 ------------
 
@@ -67,6 +69,8 @@ system.
 In practice, class :cpp:class:`Object` is the variant of the three above that
 the |ns3| developer will most commonly encounter.
 
+.. _Memory-management-and-class-Ptr:
+
 Memory management and class Ptr
 *******************************
 
diff --git a/doc/manual/source/object-names.rst b/doc/manual/source/object-names.rst
index a50e7bd2b..932485368 100644
--- a/doc/manual/source/object-names.rst
+++ b/doc/manual/source/object-names.rst
@@ -1,5 +1,7 @@
 .. include:: replace.txt
 
+.. _Object-names:
+
 Object names
 ------------
 
diff --git a/doc/manual/source/python.rst b/doc/manual/source/python.rst
index 564b31436..c22392ab3 100644
--- a/doc/manual/source/python.rst
+++ b/doc/manual/source/python.rst
@@ -239,9 +239,9 @@ Organization of the Monolithic Python Bindings
 
 The monolithic Python API definitions are organized as follows. For each |ns3| module , the file ``bindings/python/ns3_module_.py`` describes its API.  Each of those files have 3 toplevel functions:
 
-#. :cpp:func:`def register_types(module)`: this function takes care of registering new types (e.g. C++ classes, enums) that are defined in tha module;
-#. :cpp:func:`def register_methods(module)`: this function calls, for each class , another function register_methods_Ns3(module).  These latter functions add method definitions for each class;
-#. :cpp:func:`def register_functions(module)`: this function registers |ns3| functions that belong to that module.
+#. :py:func:`def register_types(module)`: this function takes care of registering new types (e.g. C++ classes, enums) that are defined in tha module;
+#. :py:func:`def register_methods(module)`: this function calls, for each class , another function register_methods_Ns3(module).  These latter functions add method definitions for each class;
+#. :py:func:`def register_functions(module)`: this function registers |ns3| functions that belong to that module.
 
 Modular Python Bindings
 ***********************
diff --git a/doc/manual/source/tracing.rst b/doc/manual/source/tracing.rst
index 9f138bfb2..27ca6f1a4 100644
--- a/doc/manual/source/tracing.rst
+++ b/doc/manual/source/tracing.rst
@@ -264,7 +264,7 @@ list, so "/NodeList/0" refers to the zeroth node in the list of nodes created by
 the simulation. This node is actually a ``Ptr`` and so is a subclass of
 an :cpp:class:`ns3::Object`.  
 
-As described in the :ref:`Object Model` section, |ns3| supports an object
+As described in the :ref:`Object-model` section, |ns3| supports an object
 aggregation model. The next path segment begins with the "$" character which
 indicates a ``GetObject`` call should be made looking for the type that follows.
 When a node is initialized by an ``InternetStackHelper`` a number of interfaces
diff --git a/doc/models/Makefile b/doc/models/Makefile
index 4a6f157ac..c68335b99 100644
--- a/doc/models/Makefile
+++ b/doc/models/Makefile
@@ -45,6 +45,7 @@ SOURCES = \
 	$(SRC)/wifi/doc/wifi.rst \
 	$(SRC)/wimax/doc/wimax.rst \
 	$(SRC)/uan/doc/uan.rst \
+	$(SRC)/topology-read/doc/topology.rst \
 	$(SRC)/stats/doc/statistics.rst \
 	$(SRC)/netanim/doc/animation.rst \
 	$(SRC)/flow-monitor/doc/flow-monitor.rst \
diff --git a/doc/tutorial/source/conclusion.rst b/doc/tutorial/source/conclusion.rst
index 53be0d3f3..20b256fa1 100644
--- a/doc/tutorial/source/conclusion.rst
+++ b/doc/tutorial/source/conclusion.rst
@@ -7,17 +7,8 @@ Conclusion
 Futures
 *******
 
-This document is a work in process.  We hope and expect it to grow over time
-to cover more and more of the nuts and bolts of |ns3|.  
-
-We hope to add the following chapters over the next few releases:
-
-* The Callback System
-* The Object System and Memory Management
-* The Routing System
-* Adding a New NetDevice and Channel
-* Adding a New Protocol
-* Working with Real Networks and Hosts
+This document is intended as a living document.  We hope and expect it to 
+grow over time to cover more and more of the nuts and bolts of |ns3|.  
 
 Writing manual and tutorial chapters is not something we all get excited about,
 but it is very important to the project.  If you are an expert in one of these
@@ -28,10 +19,13 @@ Closing
 *******
 
 |ns3| is a large and complicated system.  It is impossible to cover all 
-of the things you will need to know in one small tutorial.
+of the things you will need to know in one small tutorial.  Readers
+who want to learn more are encouraged to read the following additional
+documentation:
 
-We have really just scratched the surface of |ns3| in this tutorial, 
-but we hope to have covered enough to get you started doing useful networking 
-research using our favorite simulator.
+* The |ns3| manual
+* The |ns3| model library documentatio
+* The |ns3| Doxygen (API documentation)
+* The |ns3| wiki
 
 -- The |ns3| development team.
diff --git a/doc/tutorial/source/getting-started.rst b/doc/tutorial/source/getting-started.rst
index 7f19084be..e318f5f1e 100644
--- a/doc/tutorial/source/getting-started.rst
+++ b/doc/tutorial/source/getting-started.rst
@@ -53,7 +53,6 @@ that approach, you can get a copy of ``ns-3-allinone`` by typing the
 following into your Linux shell (assuming you have installed Mercurial):
 
 ::
-
   cd
   mkdir repos
   cd repos
@@ -69,11 +68,12 @@ following displayed,
   adding changesets
   adding manifests
   adding file changes
-  added 31 changesets with 45 changes to 7 files
+  added 47 changesets with 67 changes to 7 files
+  updating to branch default
   7 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
 After the clone command completes, you should have a directory called 
-``ns-3-allinone`` under your ``~/repos`` directory, the contents of which should 
+``ns-3-allinone``, the contents of which should 
 look something like the following:
 
 ::
@@ -221,7 +221,7 @@ As mentioned above, one practice is to create a directory called ``repos``
 in one's home directory under which one can keep local Mercurial repositories.
 One could also keep a ``tarballs`` directory.  *Hint:  the tutorial
 will assume you downloaded into a ``repos`` directory, so remember the
-placekeeper.``*  If you adopt the ``tarballs`` directory approach, you can 
+placekeeper.*  If you adopt the ``tarballs`` directory approach, you can 
 get a copy of a release by typing the following into your Linux shell 
 (substitute the appropriate version numbers, of course):
 
@@ -230,15 +230,15 @@ get a copy of a release by typing the following into your Linux shell
   cd
   mkdir tarballs
   cd tarballs
-  wget http://www.nsnam.org/releases/ns-allinone-3.10.tar.bz2
-  tar xjf ns-allinone-3.10.tar.bz2
+  wget http://www.nsnam.org/releases/ns-allinone-3.13.tar.bz2
+  tar xjf ns-allinone-3.13.tar.bz2
 
-If you change into the directory ``ns-allinone-3.10`` you should see a
+If you change into the directory ``ns-allinone-3.13`` you should see a
 number of files:
 
 ::
 
-  build.py      ns-3.10/      pybindgen-0.15.0/    util.py
+  build.py      ns-3.13/      pybindgen-0.15.0.795/    util.py
   constants.py  nsc-0.5.2/    README  
 
 You are now ready to build the |ns3| distribution.
@@ -248,16 +248,20 @@ Building ns-3
 
 Building with build.py
 ++++++++++++++++++++++
-The first time you build the |ns3| project you should build using the
-``allinone`` environment.  This will get the project configured for you
-in the most commonly useful way.
+The first time you build the |ns3| project you can build using a 
+convenience program found in the
+``allinone`` directory.  This program is called ``build.py``.  This 
+program will get the project configured for you
+in the most commonly useful way.  However, please note that more advanced
+configuration and work with |ns3| will typically involve using the
+native |ns3| build system, Waf, to be introduced later in this tutorial.  
 
 Change into the directory you created in the download section above.  If you
 downloaded using Mercurial you should have a directory called 
 ``ns-3-allinone`` under your ``~/repos`` directory.  If you downloaded
 using a tarball you should have a directory called something like 
-``ns-allinone-3.10`` under your ``~/tarballs`` directory.  Take a deep
-breath and type the following:
+``ns-allinone-3.13`` under your ``~/tarballs`` directory.  
+Type the following:
 
 ::
 
@@ -265,8 +269,10 @@ breath and type the following:
 
 Because we are working with examples and tests in this tutorial, and
 because they are not built by default in |ns3|, the arguments for
-build.py tells it to build them for us.  In the future you can build
-|ns3| without examples and tests if you wish.
+build.py tells it to build them for us.  The program also defaults to
+building all available modules.  Later, you can build
+|ns3| without examples and tests, or eliminate the modules that
+are not necessary for your work, if you wish.
 
 You will see lots of typical compiler output messages displayed as the build
 script builds the various pieces you downloaded.  Eventually you should see the
@@ -274,7 +280,7 @@ following magic words:
 
 ::
 
-  Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
+  Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3.13/build'
   'build' finished successfully (2m30.586s)
   
   Modules built: 
@@ -292,12 +298,12 @@ following magic words:
   topology-read             uan                       virtual-net-device
   visualizer                wifi                      wimax
 
-Once the project has built you can say goodbye to your old friends, the 
+Once the project has built, you can stop working with the
 ``ns-3-allinone`` scripts.  You got what you needed from them and will now 
-interact directly with Waf and we do it in the ``ns-3-dev`` directory,
+interact directly with Waf and we do it in the |ns3| directory,
 not in the ``ns-3-allinone`` directory.  Go ahead and change into the 
-``ns-3-dev`` directory (or the directory for the appropriate release you
-downloaded.
+|ns3| directory (or the directory for the appropriate release  or
+development snapshot that you downloaded; e.g.  
 
 ::
 
@@ -305,7 +311,8 @@ downloaded.
 
 Building with Waf
 +++++++++++++++++
-We use Waf to configure and build the |ns3| project.  It's not 
+Most users directly use Waf to configure and build the |ns3| project.  
+It's not 
 strictly required at this point, but it will be valuable to take a slight
 detour and look at how to make changes to the configuration of the project.
 Probably the most useful configuration change you can make will be to 
@@ -313,14 +320,19 @@ build the optimized version of the code.  By default you have configured
 your project to build the debug version.  Let's tell the project to 
 make an optimized build.  To explain to Waf that it should do optimized
 builds that include the examples and tests, you will need to execute the 
-following command,
+following commands,
 
 ::
 
+  ./waf clean
   ./waf -d optimized --enable-examples --enable-tests configure
 
 This runs Waf out of the local directory (which is provided as a convenience
-for you).  As the build system checks for various dependencies you should see
+for you).  The first command to clean out the previous build is not 
+typically strictly necessary but is good practice; it will remove the
+previously built libraries and object files found in directory ``build/``. 
+When the project is reconfigured and the build system checks for various 
+dependencies, you should see
 output that looks similar to the following,
 
 ::
@@ -396,15 +408,20 @@ Now go ahead and switch back to the debug build that includes the examples and t
 
 ::
 
+  ./waf clean
   ./waf -d debug --enable-examples --enable-tests configure
 
 The build system is now configured and you can build the debug versions of 
-the |ns3| programs by simply typing,
+the |ns3| programs by simply typing
 
 ::
 
   ./waf
 
+Okay, sorry, I made you build the |ns3| part of the system twice,
+but now you know how to change the configuration and build optimized code.
+
+Here are a few more introductory tips about Waf.
 Some waf commands are meaningful during the build phase and some commands are valid
 in the configuration phase.  For example, if you wanted to use the emulation 
 features of |ns3|, you might want to enable setting the suid bit using
@@ -425,8 +442,17 @@ available in waf.  To explore these options, type:
 
 We'll use some of the testing-related commands in the next section.
 
-Okay, sorry, I made you build the |ns3| part of the system twice,
-but now you know how to change the configuration and build optimized code.
+Finally, as an aside, it is possible to specify that waf builds the 
+project in 
+a directory different than the default ``build/`` directory by passing
+the ``-o`` option to configure; e.g.
+
+::
+
+  ./waf -d debug -o build/debug --enable-examples --enable-tests configure
+
+This allows users to work with multiple builds rather than always
+overwriting the last build.
 
 Testing ns-3
 ************
@@ -443,7 +469,7 @@ see a report saying that,
 
 ::
 
-  47 of 47 tests passed (47 passed, 0 failed, 0 crashed, 0 valgrind errors)
+  92 of 92 tests passed (92 passed, 0 failed, 0 crashed, 0 valgrind errors)
 
 This is the important message.
 
@@ -486,9 +512,9 @@ You will also see output from the test runner and the output will actually look
   PASS: TestSuite basic-random-number
   PASS: TestSuite object
   PASS: TestSuite random-number-generators
-  95 of 95 tests passed (95 passed, 0 failed, 0 crashed, 0 valgrind errors)
+  92 of 92 tests passed (92 passed, 0 failed, 0 crashed, 0 valgrind errors)
 
-This command is typically run by ``users`` to quickly verify that an 
+This command is typically run by users to quickly verify that an 
 |ns3| distribution has built correctly.  
 
 Running a Script
diff --git a/doc/tutorial/source/introduction.rst b/doc/tutorial/source/introduction.rst
index f733c72ce..93e70d800 100644
--- a/doc/tutorial/source/introduction.rst
+++ b/doc/tutorial/source/introduction.rst
@@ -25,48 +25,49 @@ A few key points are worth noting at the onset:
 * Ns-3 is not an extension of `ns-2
   `_; 
   it is a new simulator.  The two simulators are both written in C++ but 
-  |ns3| is a new simulator that does not support the ns-2 APIs.  Some 
-  models from ns-2 have already been ported from ns-2 to |ns3|. The 
-  project will continue to maintain ns-2 while |ns3| is being built,
+  |ns3| is a new simulator that does not support the |ns2| APIs.  Some 
+  models from |ns2| have already been ported from |ns2| to |ns3|. The 
+  project will continue to maintain |ns2| while |ns3| is being built,
   and will study transition and integration mechanisms.
 * |ns3| is open-source, and the project strives to maintain an 
-  open  environment for researchers to contribute and share their software.  
+  open environment for researchers to contribute and share their software.  
 
  
-For ns-2 Users
-**************
+For |ns2| Users
+***************
 
-For those familiar with ns-2, the most visible outward change when moving to 
-|ns3| is the choice of scripting language.  Ns-2 is 
+For those familiar with |ns2|, the most visible outward change when moving to 
+|ns3| is the choice of scripting language.  Programs in |ns2| are 
 scripted in OTcl and results of simulations can be visualized using the 
 Network Animator nam.  It is not possible to run a simulation
-in ns-2 purely from C++ (i.e., as a main() program without any OTcl).
-Moreover, some components of ns-2 are written in C++ and others in OTcl.
+in |ns2| purely from C++ (i.e., as a main() program without any OTcl).
+Moreover, some components of |ns2| are written in C++ and others in OTcl.
 In |ns3|, the simulator is written entirely in C++, with optional
 Python bindings.  Simulation scripts can therefore be written in C++
-or in Python.  The results of some simulations can be visualized by
-nam, but new animators are under development.  Since |ns3|
+or in Python.  New animators and visualizers are available and under
+current development.  Since |ns3|
 generates pcap packet trace files, other utilities can be used to
 analyze traces as well.
 In this tutorial, we will first concentrate on scripting 
 directly in C++ and interpreting results via trace files.  
 
 But there are similarities as well (both, for example, are based on C++ 
-objects, and some code from ns-2 has already been ported to |ns3|).
-We will try to highlight differences between ns-2 and |ns3|
+objects, and some code from |ns2| has already been ported to |ns3|).
+We will try to highlight differences between |ns2| and |ns3|
 as we proceed in this tutorial.
 
-A question that we often hear is "Should I still use ns-2 or move to
+A question that we often hear is "Should I still use |ns2| or move to
 |ns3|?"  The answer is that it depends.  |ns3| does not have
-all of the models that ns-2 currently has, but on the other hand, |ns3|
+all of the models that |ns2| currently has, but on the other hand, |ns3|
 does have new capabilities (such as handling multiple interfaces on nodes 
 correctly, use of IP addressing and more alignment with Internet
-protocols and designs, more detailed 802.11 models, etc.).  ns-2
-models can usually be ported to |ns3| (a porting guide is under
-development).  There is active development on multiple fronts for 
-|ns3|.  The |ns3| developers believe (and certain early users
-have proven) that |ns3| is ready for active use, and should be an 
-attractive alternative for users looking to start new simulation projects.  
+protocols and designs, more detailed 802.11 models, etc.).  |ns2|
+models can sometimes be ported to |ns3| (a porting guide is under
+development).  The support available on the user mailing list, and the
+developer and maintainer activity, is higher for |ns3|.  A good guideline
+would be to look at both simulators, and in particular the models available
+for your research, but when in doubt or when starting new simulation 
+projects, choose the tool that is under more active development (|ns3|).
 
 Contributing
 ************
@@ -75,13 +76,13 @@ Contributing
 research community.  It will rely on the ongoing contributions of the 
 community to develop new models, debug or maintain existing ones, and share 
 results.  There are a few policies that we hope will encourage people to 
-contribute to |ns3| like they have for ns-2:
+contribute to |ns3| like they have for |ns2|:
 
 * Open source licensing based on GNU GPLv2 compatibility
 * `wiki
   `_
 * `Contributed Code
-  `_ page, similar to ns-2's popular Contributed Code
+  `_ page, similar to |ns2|'s popular Contributed Code
   `page
   `_ 
 * Open `bug tracker
diff --git a/doc/tutorial/source/resources.rst b/doc/tutorial/source/resources.rst
index 34e77b776..c2b61c5c0 100644
--- a/doc/tutorial/source/resources.rst
+++ b/doc/tutorial/source/resources.rst
@@ -10,7 +10,7 @@ There are several important resources of which any |ns3| user must be
 aware.  The main web site is located at http://www.nsnam.org and 
 provides access to basic information about the |ns3| system.  Detailed 
 documentation is available through the main web site at
-http://www.nsnam.org/documents.html.  You can also find documents 
+http://www.nsnam.org/documentation/.  You can also find documents 
 relating to the system architecture from this page.
 
 There is a Wiki that complements the main |ns3| web site which you will
@@ -61,9 +61,7 @@ using the Python language.
 
 The build system Waf is used on the |ns3| project.  It is one 
 of the new generation of Python-based build systems.  You will not need to 
-understand any Python to build the existing |ns3| system, and will 
-only have to understand a tiny and intuitively obvious subset of Python in 
-order to extend the system in most cases.
+understand any Python to build the existing |ns3| system.
 
 For those interested in the gory details of Waf, the main web site can be 
 found at http://code.google.com/p/waf/.
@@ -72,7 +70,7 @@ Development Environment
 ***********************
 
 As mentioned above, scripting in |ns3| is done in C++ or Python.
-As of ns-3.2, most of the |ns3| API is available in Python, but the 
+Most of the |ns3| API is available in Python, but the 
 models are written in C++ in either case.  A working 
 knowledge of C++ and object-oriented concepts is assumed in this document.
 We will take some time to review some of the more advanced concepts or 
@@ -98,26 +96,10 @@ neither make nor autotools.  We use Waf for these functions.
 Typically an |ns3| author will work in Linux or a Linux-like
 environment.  For those running under Windows, there do exist environments 
 which simulate the Linux environment to various degrees.  The |ns3| 
-project supports development in the Cygwin environment for 
+project has in the past (but not presently) supported development in the Cygwin environment for 
 these users.  See http://www.cygwin.com/ 
-for details on downloading (MinGW is presently not officially supported,
-although some of the project maintainers to work with it). Cygwin provides 
-many of the popular Linux system commands.  It can, however, sometimes be 
-problematic due to the way it actually does its emulation, and sometimes
-interactions with other Windows software can cause problems.
-
-If you do use Cygwin or MinGW; and use Logitech products, we will save you
-quite a bit of heartburn right off the bat and encourage you to take a look
-at the `MinGW FAQ
-`_.
-
-Search for "Logitech" and read the FAQ entry, "why does make often 
-crash creating a sh.exe.stackdump file when I try to compile my source code."
-Believe it or not, the ``Logitech Process Monitor`` insinuates itself into
-every DLL in the system when it is running.  It can cause your Cygwin or
-MinGW DLLs to die in mysterious ways and often prevents debuggers from 
-running.  Beware of Logitech software when using Cygwin.
-
+for details on downloading, and visit the |ns3| wiki for more information
+about Cygwin and |ns3|.  MinGW is presently not officially supported.
 Another alternative to Cygwin is to install a virtual machine environment
 such as VMware server and install a Linux virtual machine.
 
diff --git a/src/click/doc/click.rst b/src/click/doc/click.rst
index 70efe9778..6af1e254b 100644
--- a/src/click/doc/click.rst
+++ b/src/click/doc/click.rst
@@ -89,6 +89,12 @@ configure ns-3 with Click Integration support::
 
   $: ./waf configure --enable-examples --enable-tests --with-nsclick=/path/to/click/source
 
+Hint:  If you have click installed one directory above ns-3 (such as in the
+ns-3-allinone directory), and the name of the directory is 'click' (or
+a symbolic link to the directory is named 'click'), then the --with-nsclick
+specifier is not necessary; the ns-3 build system will successfully find
+the directory.
+
 If it says 'enabled' beside 'NS-3 Click Integration Support', then you're good to go. Note: If running modular ns-3, the minimum set of modules required to run all ns-3-click examples is wifi, csma and config-store.
 
 Next, try running one of the examples::
diff --git a/src/click/model/ipv4-click-routing.cc b/src/click/model/ipv4-click-routing.cc
index 374e0e304..faf74292e 100644
--- a/src/click/model/ipv4-click-routing.cc
+++ b/src/click/model/ipv4-click-routing.cc
@@ -256,11 +256,48 @@ Ipv4ClickRouting::GetClickInstanceFromSimNode (simclick_node_t *simnode)
   return m_clickInstanceFromSimNode[simnode];
 }
 
+struct timeval
+Ipv4ClickRouting::GetTimevalFromNow () const
+{
+  struct timeval curtime;
+  uint64_t remainder = 0;
+
+  curtime.tv_sec = Simulator::Now ().GetSeconds ();
+  curtime.tv_usec = Simulator::Now ().GetMicroSeconds () % 1000000;
+
+  switch (Simulator::Now ().GetResolution()) 
+    {
+      case Time::NS:
+        remainder = Simulator::Now ().GetNanoSeconds () % 1000;
+        break;
+      case Time::PS:
+        remainder = Simulator::Now ().GetPicoSeconds () % 1000000;
+        break;
+      case Time::FS:
+        remainder = Simulator::Now ().GetFemtoSeconds () % 1000000000;
+        break;
+      default:
+        break;
+    }
+
+  if (remainder)
+    {
+      ++curtime.tv_usec;
+      if (curtime.tv_usec == 1000000)
+        {
+          ++curtime.tv_sec;
+          curtime.tv_usec = 0;
+        }
+    }
+
+  return curtime;
+}
+
 void
 Ipv4ClickRouting::RunClickEvent ()
 {
-  m_simNode->curtime.tv_sec = Simulator::Now ().GetSeconds ();
-  m_simNode->curtime.tv_usec = Simulator::Now ().GetMicroSeconds () % 1000000;
+  m_simNode->curtime = GetTimevalFromNow ();
+
   NS_LOG_DEBUG ("RunClickEvent at " << m_simNode->curtime.tv_sec << " " << 
                                        m_simNode->curtime.tv_usec << " " << Simulator::Now ());
   simclick_click_run (m_simNode);
@@ -311,8 +348,7 @@ void
 Ipv4ClickRouting::SendPacketToClick (int ifid, int ptype, const unsigned char* data, int len)
 {
   NS_LOG_FUNCTION (this << ifid);
-  m_simNode->curtime.tv_sec = Simulator::Now ().GetSeconds ();
-  m_simNode->curtime.tv_usec = Simulator::Now ().GetMicroSeconds () % 1000000;
+  m_simNode->curtime = GetTimevalFromNow ();
 
   // Since packets in ns-3 don't have global Packet ID's and Flow ID's, we
   // feed dummy values into pinfo. This avoids the need to make changes in the Click code
diff --git a/src/click/model/ipv4-click-routing.h b/src/click/model/ipv4-click-routing.h
index d15be9339..bce625be3 100644
--- a/src/click/model/ipv4-click-routing.h
+++ b/src/click/model/ipv4-click-routing.h
@@ -180,6 +180,11 @@ private:
    */
   void AddSimNodeToClickMapping ();
 
+  /**
+   * \brief Get current simulation time as a timeval
+   */
+  struct timeval GetTimevalFromNow () const;
+
   /**
    * \brief This method has to be scheduled everytime Click calls SIMCLICK_SCHEDULE
    */
diff --git a/src/create-module.py b/src/create-module.py
index 38622662b..f1fb486ce 100755
--- a/src/create-module.py
+++ b/src/create-module.py
@@ -19,6 +19,11 @@ def build(bld):
         'helper/%(MODULE)s-helper.cc',
         ]
 
+    module_test = bld.create_ns3_module_test_library('%(MODULE)s')
+    module_test.source = [
+        'test/%(MODULE)s-test-suite.cc',
+        ]
+
     headers = bld.new_task_gen(features=['ns3header'])
     headers.module = %(MODULE)r
     headers.source = [
@@ -135,6 +140,76 @@ main (int argc, char *argv[])
 '''
 
 
+TEST_CC_TEMPLATE = '''/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
+
+// Include a header file from your module to test.
+#include "ns3/%(MODULE)s.h"
+
+// An essential include is test.h
+#include "ns3/test.h"
+
+// Do not put your test classes in namespace ns3.  You may find it useful
+// to use the using directive to access the ns3 namespace directly
+using namespace ns3;
+
+// This is an example TestCase.
+class %(CAPITALIZED)sTestCase1 : public TestCase
+{
+public:
+  %(CAPITALIZED)sTestCase1 ();
+  virtual ~%(CAPITALIZED)sTestCase1 ();
+
+private:
+  virtual void DoRun (void);
+};
+
+// Add some help text to this case to describe what it is intended to test
+%(CAPITALIZED)sTestCase1::%(CAPITALIZED)sTestCase1 ()
+  : TestCase ("%(CAPITALIZED)s test case (does nothing)")
+{
+}
+
+// This destructor does nothing but we include it as a reminder that
+// the test case should clean up after itself
+%(CAPITALIZED)sTestCase1::~%(CAPITALIZED)sTestCase1 ()
+{
+}
+
+//
+// This method is the pure virtual method from class TestCase that every
+// TestCase must implement
+//
+void
+%(CAPITALIZED)sTestCase1::DoRun (void)
+{
+  // A wide variety of test macros are available in src/core/test.h
+  NS_TEST_ASSERT_MSG_EQ (true, true, "true doesn't equal true for some reason");
+  // Use this one for floating point comparisons
+  NS_TEST_ASSERT_MSG_EQ_TOL (0.01, 0.01, 0.001, "Numbers are not equal within tolerance");
+}
+
+// The TestSuite class names the TestSuite, identifies what type of TestSuite,
+// and enables the TestCases to be run.  Typically, only the constructor for
+// this class must be defined
+//
+class %(CAPITALIZED)sTestSuite : public TestSuite
+{
+public:
+  %(CAPITALIZED)sTestSuite ();
+};
+
+%(CAPITALIZED)sTestSuite::%(CAPITALIZED)sTestSuite ()
+  : TestSuite ("%(MODULE)s", UNIT)
+{
+  AddTestCase (new %(CAPITALIZED)sTestCase1);
+}
+
+// Do not forget to allocate an instance of this TestSuite
+static %(CAPITALIZED)sTestSuite %(MODULE)sTestSuite;
+
+'''
+
+
 def main(argv):
     parser = OptionParser(usage=("Usage: %prog [options] modulename\n"
                                  "Utility script to create a basic template for a new ns-3 module"))
@@ -174,6 +249,17 @@ def main(argv):
 
 
 
+    #
+    # test
+    # 
+    testdir = os.path.join(moduledir, "test")
+    os.mkdir(testdir)
+    test_cc = file(os.path.join(moduledir, "test", "%s-test-suite.cc" % modname), "wt")
+    test_cc.write(TEST_CC_TEMPLATE % dict(MODULE=modname,CAPITALIZED=modname.capitalize()))
+    test_cc.close()
+
+
+
     #
     # helper
     # 
diff --git a/src/internet/doc/routing-overview.rst b/src/internet/doc/routing-overview.rst
index 3d2d64d8c..5e2b12b54 100644
--- a/src/internet/doc/routing-overview.rst
+++ b/src/internet/doc/routing-overview.rst
@@ -6,10 +6,13 @@ Routing overview
 |ns3| is intended to support traditional routing approaches and protocols,
 support ports of open source routing implementations, and facilitate research
 into unorthodox routing techniques. The overall routing architecture is
-described below in :ref:`Routing architecture`. Users who wish to just read
-about how to configure global routing for wired topologies can read :ref:`Global
-centralized routing`. Unicast routing protocols are described in :ref:`Unicast
-routing`. Multicast routing is documented in :ref:`Multicast routing`.
+described below in :ref:`Routing-architecture`. Users who wish to just read
+about how to configure global routing for wired topologies can read 
+:ref:`Global-centralized-routing`. Unicast routing protocols are described in 
+:ref:`Unicast-routing`.  Multicast routing is documented in 
+:ref:`Multicast-routing`.
+
+.. _Routing-architecture:
 
 Routing architecture
 ********************
@@ -72,11 +75,13 @@ prioritized routing protocols (Ipv4ListRouting::AddRoutingProtocol(),
 Ipv4ListRouting::GetRoutingProtocol()).
 
 The details of these routing protocols are described below in
-:ref:`Unicast routing`.  For now, we will first start with a basic
+:ref:`Unicast-routing`.  For now, we will first start with a basic
 unicast routing capability that is intended to globally build routing
 tables at simulation time t=0 for simulation users who do not care
 about dynamic routing.
 
+.. _Global-centralized-routing:
+
 Global centralized routing
 **************************
 
@@ -204,6 +209,8 @@ Advertisement for each router, and this link state database is
 fed into the OSPF shortest path computation logic. The Ipv4 API
 is finally used to populate the routes themselves. 
 
+.. _Unicast-routing:
+
 Unicast routing
 ***************
 
@@ -321,6 +328,8 @@ respond to dynamic changes to a device's IP address or link up/down
 notifications; i.e. the topology changes are due to loss/gain of connectivity
 over a wireless channel.
 
+.. _Multicast-routing:
+
 Multicast routing
 *****************
 
diff --git a/src/internet/doc/tcp.rst b/src/internet/doc/tcp.rst
index b8a1c8042..bacb97773 100644
--- a/src/internet/doc/tcp.rst
+++ b/src/internet/doc/tcp.rst
@@ -93,7 +93,7 @@ helper API, the TCP that is aggregated to nodes with an Internet stack is the
 native |ns3| TCP.
 
 To configure behavior of TCP, a number of parameters are exported through the
-:ref:`Attributes `. These are documented in the `Doxygen
+|ns3| attribute system. These are documented in the `Doxygen
 ` for class
 :cpp:class:`TcpSocket`.  For example, the maximum segment size is a
 settable attribute.
@@ -137,7 +137,7 @@ the specified node, one would have to do something like:::
 
 Once a TCP socket is created, one will want to follow conventional socket logic
 and either connect() and send() (for a TCP client) or bind(), listen(), and
-accept() (for a TCP server). :ref:`Sockets API ` for a review of
+accept() (for a TCP server). See :ref:`Sockets-APIs` for a review of
 how sockets are used in |ns3|.
 
 Validation
@@ -255,7 +255,7 @@ sockets, as described above and documented in `Doxygen
 `_
 
 Additionally, NSC TCP exports a lot of configuration variables into the 
-|ns3| :ref:`Attributes` system, via a `sysctl `_-like interface. In the ``examples/tcp/tcp-nsc-zoo`` example, you
+|ns3| attributes system, via a `sysctl `_-like interface. In the ``examples/tcp/tcp-nsc-zoo`` example, you
 can see the following configuration:::
 
 
diff --git a/src/internet/model/ipv6-raw-socket-factory.h b/src/internet/model/ipv6-raw-socket-factory.h
index a9ed03bb8..c049266ac 100644
--- a/src/internet/model/ipv6-raw-socket-factory.h
+++ b/src/internet/model/ipv6-raw-socket-factory.h
@@ -35,6 +35,29 @@ class Socket;
  *
  * This abstract class defines the API for IPv6 RAW socket factory.
  * 
+ * A RAW Socket typically is used to access specific IP layers not usually
+ * available through L4 sockets, e.g., ICMP. The implementer should take
+ * particular care to define the Ipv6RawSocketImpl Attributes, and in
+ * particular the Protocol attribute.
+ * Not setting it will result in a zero protocol at IP level (corresponding
+ * to the HopByHop IPv6 Extension header, i.e., Ipv6ExtensionHopByHopHeader)
+ * when sending data through the socket, which is probably not the intended
+ * behavior.
+ *
+ * A correct example is (from src/applications/model/radvd.cc):
+ * \code
+   if (!m_socket)
+     {
+       TypeId tid = TypeId::LookupByName ("ns3::Ipv6RawSocketFactory");
+       m_socket = Socket::CreateSocket (GetNode (), tid);
+
+       NS_ASSERT (m_socket);
+
+       m_socket->SetAttribute ("Protocol", UintegerValue(Ipv6Header::IPV6_ICMPV6));
+       m_socket->SetRecvCallback (MakeCallback (&Radvd::HandleRead, this));
+     }
+ * \endcode
+ *
  */
 class Ipv6RawSocketFactory : public SocketFactory
 {
diff --git a/src/internet/model/ipv6-raw-socket-impl.h b/src/internet/model/ipv6-raw-socket-impl.h
index 1f80fd2d6..10581a447 100644
--- a/src/internet/model/ipv6-raw-socket-impl.h
+++ b/src/internet/model/ipv6-raw-socket-impl.h
@@ -36,6 +36,30 @@ class Node;
 /**
  * \class Ipv6RawSocketImpl
  * \brief IPv6 raw socket.
+ *
+ * A RAW Socket typically is used to access specific IP layers not usually
+ * available through L4 sockets, e.g., ICMP. The implementer should take
+ * particular care to define the Ipv6RawSocketImpl Attributes, and in
+ * particular the Protocol attribute.
+ * Not setting it will result in a zero protocol at IP level (corresponding
+ * to the HopByHop IPv6 Extension header, i.e., Ipv6ExtensionHopByHopHeader)
+ * when sending data through the socket, which is probably not the intended
+ * behavior.
+ *
+ * A correct example is (from src/applications/model/radvd.cc):
+ * \code
+   if (!m_socket)
+     {
+       TypeId tid = TypeId::LookupByName ("ns3::Ipv6RawSocketFactory");
+       m_socket = Socket::CreateSocket (GetNode (), tid);
+
+       NS_ASSERT (m_socket);
+
+       m_socket->SetAttribute ("Protocol", UintegerValue(Ipv6Header::IPV6_ICMPV6));
+       m_socket->SetRecvCallback (MakeCallback (&Radvd::HandleRead, this));
+     }
+ * \endcode
+ *
  */
 class Ipv6RawSocketImpl : public Socket
 {
diff --git a/src/mobility/helper/ns2-mobility-helper.h b/src/mobility/helper/ns2-mobility-helper.h
index abc40fbc2..d17b15471 100644
--- a/src/mobility/helper/ns2-mobility-helper.h
+++ b/src/mobility/helper/ns2-mobility-helper.h
@@ -50,12 +50,22 @@ class ConstantVelocityMobilityModel;
    $ns at $time $node set Z_ Z1
  \endverbatim
  *
- * Following tools are known to support this format:
+ * The following tools are known to support this format:
  *  - BonnMotion http://net.cs.uni-bonn.de/wg/cs/applications/bonnmotion/
  *  - SUMO http://sourceforge.net/apps/mediawiki/sumo/index.php?title=Main_Page
  *  - TraNS http://trans.epfl.ch/ 
  *
  *  See usage example in examples/mobility/ns2-mobility-trace.cc
+ *
+ * \bug Traces that generate initial position statements at the end of the
+ * mobility file (e.g. SUMO TraceExporter) will not be read correctly.  The
+ * workaround is to relocate these three initial position statements to the
+ * beginning of the trace.  
+ * See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1316
+ *
+ * \bug Rounding errors may cause movement to diverge from the mobility
+ * pattern in ns-2 (using the same trace).
+ * See https://www.nsnam.org/bugzilla/show_bug.cgi?id=1316
  */
 class Ns2MobilityHelper
 {
diff --git a/src/netanim/doc/animation.rst b/src/netanim/doc/animation.rst
index c0f833297..37877b94c 100644
--- a/src/netanim/doc/animation.rst
+++ b/src/netanim/doc/animation.rst
@@ -4,97 +4,45 @@ Animation
 ---------
 
 Animation is an important tool for network simulation. While |ns3| does not
-contain a default graphical animation tool, it does provide an animation
-interface for use with stand-alone animators. One such animator called NetAnim,
-presently supporting packet flow animation for point-to-point links, has been
-developed. Other animators and visualization tools are in development; they may
-make use of the existing animation interface or may develop new ones,   
+contain a default graphical animation tool, we currently have two ways to provide
+animation, namely using the PyViz method or the NetAnim method.
+The PyViz method is described in http://www.nsnam.org/wiki/index.php/PyViz.
+The NetAnim method is described in detail at http://www.nsnam.org/wiki/index.php/NetAnim.
+We will describe the NetAnim method briefly here.
 
-Animation interface
+AnimationInterface
 *******************
 
-The animation interface uses underlying |ns3| trace sources to construct a
-timestamped ASCII file that can be read by a standalone animator.  The animation
-interface in |ns3| currently only supports point-to-point links; however, we
-hope to support other link types such as CSMA and wireless in the near future.
-A snippet from a sample trace file is shown below.::
+The class "AnimationInterface" under "src/netanim" uses underlying |ns3| trace sources 
+to construct a timestamped ASCII file in XML format that can be read by a standalone animator 
+named "NetAnim". 
 
-    0.0 N 0 4 5.5
-    0.0 N 1 7 5.5
-    0.0 N 2 2.5 2.90192
+Generating XML trace files for use in NetAnim
++++++++++++++++++++++++++++++++++++++++++++++
+Apply the following statements before the "Simulator::Run ()" statement:::
 
-    ...
+  AnimationInterface anim ("animation.xml")
 
-    0.0 L 0 1
-    0.0 L 0 2
-    0.0 L 0 3
+where "animation.xml" is any arbitrary file name.
+It is important to ensure that your wscript includes the "netanim" module. 
+Example as in: src/netanim/examples/wscript. Also include the header 
+[#include "ns3/netanim-module.h"] in your test program
 
-    ...
+The examples under "src/netanim/examples" illustrate this. The sample wscript is at 
+"src/netanim/examples/wscript".
 
-    Running the simulation
-    0.668926 P 11 1 0.66936 0.669926 0.67036
-    0.67036 P 1 0 0.670794 0.67136 0.671794
-    0.671794 P 0 6 0.672227 0.672794 0.673227
+Lets take an example: "src/netanim/examples/star-animation.cc". To run the example:::
 
-    ...
+  ./waf --run "star-animation"
 
-The tracefile describes where nodes and links should be placed at the top of the
-file. Following this placement, the packet events are shown. The format for node
-placement, link placement and packet events is shown below.
+This will generate an xml file "star-animation.xml" in the same directory. This XML file 
+contains the information required by the standalone animator "NetAnim" to produce the required
+animation.
 
-* Node placement: