docs(network): update network readme for mapping model

Signed-off-by: Mark Sanders <marksanders194@gmail.com>

network/Networking.puml

@@ -0,0 +1,47 @@
+@startmindmap
++ IPU/DPU Networking
+++ NIC Mode
++++ Parameter Config
+++++ MTU
+++++ IP Addressing
++++++ IP Address(es)
++++++ Gateway
++++ VNIC
+++ Switch/Router Mode
++++ Cloud
++++ Bridge
++++ VRF
++++ VPN/EVPN
++++ ECMP
++++ LACP
++++ BFD
+++ K8s Networking
++++ Dataplane API
+++++ Calico
+++++ Openshift
++++ K8s Offload
++++ Secondary Network Offload
+++ Offload Services
++++ Firewall
++++ SONiC/DASH
+++ Network Virtualization
++++ OVS
+-- Tunneling
+--- VLAN
+--- VXLAN
+--- VTEP
+--- IPSec
+--- Geneve
+-- QoS
+--- Rate Limiting
+--- Policing
+--- Scheduling
+-- Policy
+--- Security Groups
+--- IP Tables
+--- NAT
+-- Security
+--- Cryptography
+--- TLS Offload
+-- Telemetry / Logging
+@endmindmap

network/OpenConfig-Model.plantuml → network/OpenConfig-Model.puml

@@ -1,4 +1,4 @@
-@startuml OpenConfig-Model.plantuml
+@startuml OpenConfig-Model.puml
 @startmindmap
 + DPU_Network_Device
 ++ Network Instance

network/README.md

@@ -8,27 +8,34 @@
 - OPI defines a __device interface__ for the data services that are delivered through the the PF/VF from the xPU.
 - OPI provides a __prototype client__ for sending gRPC, REST protobufs to the xPU for configuation and management.
 
-## Network Use Case
-
-A basic network use case is to provide a LAN/VLAN connection between two servers to allow for container and VM applications to interoperate.
-
-Configuration of the basic use case should consider the ability to setup OVS, SONiC, VPP, and P4 flows through the associated APIs.  Additionally the ability to subscribe to telemetry services such as OTEL is desired to allow for network telemetry information to be delivered.
-
-![Network Services Offload Use Case](../doc/images/API-Network-Use-Case.png)
-
-The basic setup can then be extended to include IPSec traffic flows for building additional services.
-
 ## Network APIs to be defined
 
-We have identified two network APIs that need to be defined
+At a core level there are two network APIs that need to be defined
 
 - __Configuration and Orchestration__
 - __Data Flow__
 
-There is possibly a third API that needs to be considered, __Application__ API.  This API supports the ability to provide service chaining between operations within the DPU which may be processed locally or be terminated into the PF/VF to the CPU complex that handles the Container/VMs.
+Additionally, a third API that needs to be considered, __Application__ API.  The Application API supports the ability to provide service chaining between operations within the DPU which may be processed locally or be terminated into the PF/VF to the CPU complex that handles the Container/VMs.
 
 The objective of the API definition is to identify a common programming interface; however, given the various solutions that need to be considered, there may be solution specific APIs for a particular domain.
 
+### Mapping Model
+
+When we look at the capabilities needed by the networking API, we have to consider the high level view of the operations available.  The identified high level groupings of operations/capabilities are illustrated in the diagram below along with a set of more granular settings that fall within the groupings.  The groupings consist of:
+
+- NIC Mode
+- Switch/Router Mode
+- Kubernetes (K8s) Networking
+- Offload Services
+- Network Virtualization
+- Tunneling
+- QoS
+- Policy
+- Security
+- Telemetry/Logging
+
+![Network Mapping Model](Networking-tree.png)
+
 ### Considerations
 
 The nework APIs need to consider the various deployment types that can be leveraged with the DPU/IPU solution.  These deployment types consist of, but are not limited to:
@@ -39,9 +46,20 @@ The nework APIs need to consider the various deployment types that can be levera
 
 Where each of these solutions may have a common set of API operations and a solution unique set of API operations.
 
-## Mapping Diagram
+## Network Use Cases
+
+A basic network use case is to provide a LAN/VLAN connection between two servers to allow for container and VM applications to interoperate.
+
+Configuration of the basic use case should consider the ability to setup OVS, SONiC, VPP, and P4 flows through the associated APIs.  Additionally the ability to subscribe to telemetry services such as OTEL is desired to allow for network telemetry information to be delivered.
+
+![Network Services Offload Use Case](../doc/images/API-Network-Use-Case.png)
+
+The basic setup can then be extended to include IPSec traffic flows for building additional services.
+
+
+## Industry Models
 
-Mapping models for the industry available APIs.
+There are industry available API Models that can be leveraged.
 
 ### OpenConfig Model