diff --git a/INTERNALS b/INTERNALS
new file mode 100644
index 0000000..bd4546a
--- /dev/null
+++ b/INTERNALS
@@ -0,0 +1,76 @@
+
+Here are a few notes about the LOXI processing flow.
+
+Currently there are two pieces of input for each version to be supported.
+
+(1) The original openflow.h header file.  This is parsed to extract
+identifiers such as #defines and enum definitions.  These are in the
+'canonical' directory.
+
+(2) A specially processed list of structs derived from the original
+openflow.h header file.  These are the structs that represent the
+protocol on the wire with the following minor modifications:
+** ofp_header structures instances are replaced by their contents
+** Arrays are replaced with the syntax 'data_type[length] idenitifier'.
+** Lists of objects are called out explicitly as 'list(data_type) identifier'
+** Match structures are renamed to be version specific
+** Each flavors of a flow modify (add, modify, modify strict, delete
+and delete strict) are called out as different objects
+** Each action type (for instance) is called out as its own type.
+
+Copyright 2012, Big Switch Networks, Inc.
+
+Enumerations/defines give semantic values for two contexts:
+
+* Internal management of objects, for example, the particular values that
+indicate a message is an Echo message or an action is an output action.
+These values, like the wire format, are generally not of interest to 
+the users of LOXI.
+
+* External representation of information. These are values which users of
+LOXI need to know about, at least through an identifier.  Examples include
+OFP_TCP_PORT, OFP_MAX_TABLE_NAME_LEN or OFPP_MAX.  
+
+In general, processing proceeds by:
+
+(1) Extracting information from each version's input files.
+
+(2) Unifying the information across all versions, allowing the
+identification of commonalities and differnces.
+
+(3) Calling the language specific generation routines for each
+target file.  The list of files to generate and the map from 
+file to generating function is given in the language specific
+Python file such as lang_c.py at the top level.
+
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+The code layout is as follows (explanations below):
+
+BigCode/Modules/
+    LoxiGen/
+        Makefile
+        loxigen.py      Entry point executable
+        of_g.py         Global variables   
+        lang_c.py, ...  Language specific
+        loxi_front_end/ Python functions for processing input
+        loxi_utils/     General utility functions
+        canonical/      openflow.h header files
+            openflow.h-<of-version>
+        openflow_input/ pre-processed openflow.h input
+            structs-<of-version>
+        c_gen/          Python functions for C code generation
+        c_template/     Template including non-autogen files
+        utest/          Simple Python scripts to test functions
+
+For C code generation, the output is placed in the BigCode module format.
+First, the C template directory is copied over to a target directory.
+Then the automatically generated files are created and placed in the
+proper locations in the target directory.  Then the result is tarred
+up for overlay onto another location.
+
+To test the code locally, the target file is untarred into a local
+directory and a special make file (in c_gen/Makefile.local) is copied
+into the local directory.
+
+