updates to core architecture diagrams leveraging plantuml, removed usage of virtual machine language in docs to help avoid confusion

docs/architecture.md

@@ -5,29 +5,34 @@
 
 ## Main Components
 
-* CORE Daemon
-  * Manages emulation sessions
-  * Builds the emulated networks using Linux namespaces for nodes and
-    some form of bridging and packet manipulation for virtual networks
-  * Nodes and networks come together via interfaces installed on nodes
+* core-daemon
+  * Manages emulated sessions of nodes and links for a given network
+  * Nodes are created using Linux namespaces
+  * Links are created using Linux bridges and virtual ethernet peers
+  * Packets sent over links are manipulated using traffic control
   * Controlled via the CORE GUI
-  * Written in python and can be scripted, given direct control of scenarios
-* CORE GUI
-  * GUI and daemon communicate using a custom, asynchronous, sockets-based
-    API, known as the CORE API
-  * Drag and drop creation for nodes and network interfaces
-  * Can launch terminals for emulated nodes in running scenarios
+  * Provides both a custo TLV API and gRPC API
+  * Python program that leverages a small C binary for node creation
+* core-gui
+  * GUI and daemon communicate over the custom TLV API
+  * Drag and drop creation for nodes and links
+  * Can launch terminals for emulated nodes in running sessions
   * Can save/open scenario files to recreate previous sessions
   * TCL/TK program
+* coresendmsg
+  * Command line utility for sending TLV API messages to the core-daemon
+* vcmd
+  * Command line utility for sending shell commands to nodes
 
-![](static/core-architecture.jpg)
+![](static/architecture.png)
 
 ## Sessions
 
-CORE can create and run multiple sessions at once, below is a high level
-overview of the states a session will go between.
+CORE can create and run multiple emulated sessions at once, below is an
+overview of the states a session will transition between during typical
+GUI interactions.
 
-![](static/core-workflow.jpg)
+![](static/workflow.png)
 
 ## How Does it Work?
 
@@ -38,7 +43,7 @@ together for a specific purpose.
 
 ### Linux
 
-Linux network namespaces (also known as netns) is the primary virtualization
+Linux network namespaces (also known as netns) is the primary
 technique used by CORE. Most recent Linux distributions have
 namespaces-enabled kernels out of the box. Each namespace has its own process
 environment and private network stack. Network namespaces share the same
@@ -56,7 +61,7 @@ The Tcl/Tk CORE GUI was originally derived from the open source
 [IMUNES](http://imunes.net) project from the University of Zagreb as a custom
 project within Boeing Research and Technology's Network Technology research
 group in 2004. Since then they have developed the CORE framework to use Linux
-virtualization, have developed a Python framework, and made numerous user and
+namespacing, have developed a Python framework, and made numerous user and
 kernel-space developments, such as support for wireless networks, IPsec,
 distribute emulation, simulation integration, and more. The IMUNES project
 also consists of userspace and kernel components.

docs/diagrams/architecture.plantuml

@@ -0,0 +1,49 @@
+@startuml
+skinparam {    
+    RoundCorner 8
+    ComponentStyle uml2
+    ComponentBorderColor #Black
+    InterfaceBorderColor #Black
+    InterfaceBackgroundColor #Yellow
+}
+
+package User {
+    component "core-gui" as gui #DeepSkyBlue
+    component "coresendmsg" #DeepSkyBlue
+    component "python scripts" as scripts #DeepSkyBlue
+    component vcmd #DeepSkyBlue
+}
+package Server {
+    component "core-daemon" as daemon #DarkSeaGreen
+}
+package Python {
+    component core #LightSteelBlue
+}
+package "Linux System" {    
+    component nodes #SpringGreen [
+        nodes
+        (linux namespaces)
+    ]    
+    component links #SpringGreen [
+        links
+        (bridging and traffic manipulation)
+    ]
+}
+
+package API {
+    interface TLV as tlv
+    interface gRPC as grpc
+}
+
+gui <..> tlv
+coresendmsg <..> tlv
+scripts <..> tlv
+scripts <..> grpc
+tlv -- daemon
+grpc -- daemon
+scripts -- core
+daemon - core
+core <..> nodes
+core <..> links
+vcmd <..> nodes
+@enduml

docs/diagrams/workflow.plantuml

@@ -0,0 +1,40 @@
+@startuml
+skinparam {    
+    RoundCorner 8
+    StateBorderColor #Black
+    StateBackgroundColor #LightSteelBlue
+}
+
+Definition: Session XML/IMN
+Definition: GUI Drawing
+Definition: Scripts
+
+Configuration: Configure Hooks
+Configuration: Configure Services
+Configuration: Configure WLAN / Mobility
+Configuration: Configure EMANE
+
+Instantiation: Create Nodes
+Instantiation: Create Interfaces
+Instantiation: Create Bridges
+Instantiation: Start Services
+
+Runtime: Interactive Shells
+Runtime: Traffic Scripts
+Runtime: Mobility
+Runtime: Widgets
+
+Datacollect: Collect Files
+Datacollect: Other Results
+
+Shutdown: Shutdown Services
+Shutdown: Destroy Brdges
+Shutdown: Destroy Interfaces
+Shutdown: Destroy Nodes
+
+Definition -> Configuration
+Configuration -> Instantiation
+Instantiation -> Runtime
+Runtime -> Datacollect
+Datacollect -> Shutdown
+@enduml

docs/gui.md

@@ -312,7 +312,7 @@ and options.
 | Change sessions... | Invokes the CORE Sessions dialog box containing a list of active CORE sessions in the daemon. Basic session information such as name, node count, start time, and a thumbnail are displayed. This dialog allows connecting to different sessions, shutting them down, or starting a new session. |
 | Node types... | Invokes the CORE Node Types dialog, performing the same function as the Edit button on the Network-Layer Nodes toolbar. |
 | Comments... | Invokes the CORE Session Comments window where optional text comments may be specified. These comments are saved at the top of the configuration file, and can be useful for describing the topology or how to use the network. |
-| Hooks... | Invokes the CORE Session Hooks window where scripts may be configured for a particular session state. The session states are defined in the table right below. The top of the window has a list of configured hooks, and buttons on the bottom left allow adding, editing, and removing hook scripts. The new or edit button will open a hook script editing window.  A hook script is a shell script invoked on the host (not within a virtual node). |
+| Hooks... | Invokes the CORE Session Hooks window where scripts may be configured for a particular session state. The session states are defined in the [table](#session-states) below. The top of the window has a list of configured hooks, and buttons on the bottom left allow adding, editing, and removing hook scripts. The new or edit button will open a hook script editing window.  A hook script is a shell script invoked on the host (not within a virtual node). |
 | Reset node positions | If you have moved nodes around using the mouse or by using a mobility module, choosing this item will reset all nodes to their original position on the canvas. The node locations are remembered when you first press the Start button. |
 | Emulation servers... | Invokes the CORE emulation servers dialog for configuring. |
 | Change Sessions... | Invokes the Sessions dialog for switching between different running sessions. This dialog is presented during startup when one or more sessions are already running. |

docs/index.md

@@ -5,7 +5,7 @@
 CORE (Common Open Research Emulator) is a tool for building virtual networks. As an emulator, CORE builds a
 representation of a real computer network that runs in real time, as opposed to simulation, where abstract models are
 used. The live-running emulation can be connected to physical networks and routers.  It provides an environment for
-running real applications and protocols, taking advantage of virtualization provided by the Linux operating system.
+running real applications and protocols, taking advantage of tools provided by the Linux operating system.
 
 CORE is typically used for network and protocol research, demonstrations, application and platform testing, evaluating
 networking scenarios, security studies, and increasing the size of physical test networks.

docs/install.md

@@ -10,12 +10,12 @@ This section will describe how to install CORE from source or from a pre-built p
 ## Required Hardware
 
 Any computer capable of running Linux should be able to run CORE. Since the physical machine will be hosting numerous
-virtual machines, as a general rule you should select a machine having as much RAM and CPU resources as possible.
+containers, as a general rule you should select a machine having as much RAM and CPU resources as possible.
 
 ## Operating System
 
-CORE requires a Linux operating system because it uses virtualization provided by the kernel. It does not run on
-Windows or Mac OS X operating systems (unless it is running within a virtual machine guest.) The virtualization
+CORE requires a Linux operating system because it uses namespacing provided by the kernel. It does not run on
+Windows or Mac OS X operating systems (unless it is running within a virtual machine guest.) The
 technology that CORE currently uses is Linux network namespaces.
 
 Ubuntu and CentOS Linux are the recommended distributions for running CORE. However, these distributions are

docs/nodetypes.md

@@ -7,15 +7,14 @@
 
 Different node types can be configured in CORE, and each node type has a
 *machine type* that indicates how the node will be represented at run time.
-Different machine types allow for different virtualization options.
+Different machine types allow for different options.
 
 ## Netns Nodes
 
 The *netns* machine type is the default. This is for nodes that will be
-backed by Linux network namespaces. This default machine type is very
-lightweight, providing a minimum amount of virtualization in order to
-emulate a network. Another reason this is designated as the default
-machine type is because this virtualization technology typically
+backed by Linux network namespaces. This machine type uses very little
+system resources in order to emulate a network. Another reason this is
+designated as the default machine type is because this technology typically
 requires no changes to the kernel; it is available out-of-the-box from the
 latest mainstream Linux distributions.
 
@@ -25,9 +24,9 @@ The *physical* machine type is used for nodes that represent a real Linux-based
 machine that will participate in the emulated network scenario. This is
 typically used, for example, to incorporate racks of server machines from an
 emulation testbed. A physical node is one that is running the CORE daemon
-(*core-daemon*), but will not be further partitioned into virtual machines.
-Services that are run on the physical node do not run in an isolated or
-virtualized environment, but directly on the operating system.
+(*core-daemon*), but will not be further partitioned into containers.
+Services that are run on the physical node do not run in an isolated
+environment, but directly on the operating system.
 
 Physical nodes must be assigned to servers, the same way nodes are assigned to
 emulation servers with *Distributed Emulation*. The list of available physical