1. Task 4 Scope – Software (L=ChrisH)
Purpose – add Software representation to the ONF CIM
Specifically – software inventory and running software. TMF TR-225 will be a good starting point + SYSAPPL-MIB (IETF RFC 2287)
Includes – Software process / thread. File system, directory and file model. Relationships to software provided functions (PC, FC etc.) which should be consistent with (running) hardware provided functions and the hardware the software is running on
Excludes – Storage model (disk, LUN, partition, extent), Hypervisor Datastore.
External Dependencies - None
Assumptions - None
Risks – Scope could get out of control.
Do we need anything special for Operating System (software) and Hypervisor ?

2. Team Members Leader - Chris Hartley chrhartl@cisco.com Members
Nigel Davis
Kam Lam

3. IPR Declaration Is there any IPR associated with this presentation NO
NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein.
THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

4. Particular Scenarios we wish to include
Hypervisor/VMM as RunningSoftware hosts VMs
VM as RunningSoftware has guest OperatingSystem
OperatingSystem as RunningSoftware enables running Applications
JVM as RunningSoftware hosts Java Applications
Eclipse as RunningSoftware hosts Java Applications
VM Image is installed element
(Linux) Container as RunningSoftware enables running Applications
Software agent as RunningSoftware
Host BIOS as RunningSoftware runs OperatingSystem ?
Device Drivers (part of OS) ?

5. Particular Scenarios we wish to exclude
IO virtualization ?
Device driver ?

6. SYSAPPL-MIB (IETF RFC 2287)
The System Application Installed group consists of two tables.
Through these two tables, administrators will be able to determine
which applications have been installed on a system and what their
constituent components are. The first table, the
sysApplInstallPkgTable, lists the application packages installed on a
particular host. The second, the sysApplInstallElmtTable, provides
information regarding the executables and non-executable files, or
elements, which collectively compose an application.
The sysApplRunTable contains the application
instances which are currently running on the host.
The sysApplPastRunTable maintains a history of instances of
applications which have previously executed on the host.
While the sysApplRunTable and sysApplPastRunTable focus on
applications as a whole, the sysApplElmtRunTable and
sysApplElmtPastRunTable provide information regarding an
application's executable elements, (processes), which are either
currently executing or have executed in the past.
Installed Application
Installed Element
Running Application
Running Element
The MIB assumes / requires a direct link between the runningElement and the installPackage which seems a bit unreasonable

7. CIM DSP140
A Software Product is a collection of software features that can be acquired as a unit. Acquisition implies an agreement between the consumer and supplier, which may have implications in terms of licensing, support, or warrantee.
A Software Feature is a collection of software elements that performs a particular function or role of a software product. This level of granularity is intended to be meaningful to a consumer or user of the application to choose. This concept allows software products or application systems to be decomposed into units that have a meaning to users rather than units that reflect how the product or application was built (i.e., software elements).
A Software Element is a collection of one or more files and associated details that are individually managed on a particular platform. It represents the level of granularity at which software features are managed.
An Application System is a collection of software features that can be managed as an independent unit that supports a particular business function.
This structure with a central key class makes more sense than the MIB structure

8. Software – Unit of Acquisition (Software Product)
Archive file (zip, tar)
Executable installer
Linux RPM or DEB
Software patch
ISO image
Physical media (CDROM, DVDROM, USB stick) with a lot of files and directories
VM images, OVF, OVA, VMDK

9. Software – Unit of Execution (Running)
Running application
Software process
thread

10. Software – Unit of Deployment (installation)
Install package
Feature
As shown in operating system install / uninstall support (windows control panel)
Software module

11. TMF TR-225 (liaised) It defines two different things:
The software inventory – what software instances have been installed
The running software processes that provide functionality, similar to how (powered up) Equipment provides functionality
The actual functionality provided by RunningSoftware is represented by the ProcessingConstruct (PC) part. This abstracts our functionality (what it does) from the implementation (how it does it). So a router may be purely software based, a mixture of software and hardware, or possibly all hardware based (using a custom ASIC).
InstalledSoftware represents software applications at a field installable level (similar to FRU for Equipment) that are installed on a ProcessingConstruct.
RunningSoftware represents the running applications, processes and threads that can provide functionality. This allows us to relate things like CPU and memory usage to the RunningSoftware. RunningSoftware is related to the InstalledSoftware. A piece of InstalledSoftware can be running more than once at any point in time.

12. Support for ‘smart chips’ with firmware
In the latest Equipment model, we added support to enable storing inventory for non-FRU Equipment. This was specifically to enable inventory of non-FRU ‘smart chips’ that can report a serial number, version etc.
Common examples include – non-removable CPU (e.g. like in a smartphone), FPGA, HDD controller, CPU north and south bridge, Ethernet controller, wireless controller, graphics accelerator
Updates are often done as part of a more general software upgrade or may be upgraded by a proprietary program
These ‘smart chips’ can often have firmware and report the firmware version, but provide no other details
To support this simple case, just having a firmwareVersion attribute in the Equipment class may be sufficient

13. File System Model
Some sort of composite is an obvious starting point, since a directory can contain directories (recursion) and files
We may want to also support symbolic links. “A symbolic link, also termed a soft link, is a special kind of file that points to another file, much like a shortcut in Windows or a Macintosh alias.”
Suggest we ignore the contents of archive files (ZIP, TAR …)
From

14. Some things to keep in mind
We need to separate the software inventory viewpoint (similar to the physical inventory viewpoint)
We need to reuse the existing functionality classes, PC and CD (not duplicate them)
We need to link this all together in a sensible fashion
Running software provides functionality (similar to running hardware)
We should allow for management of memory, CPU and storage capacity (related back to the running software)
We may need memory, CPU and storage physical inventory and functional classes
While software actually runs on hardware memory, CPU and storage, we need to decouple it (so we can also consistently represent VM hardware memory, CPU and storage)
We need to be able to show the combination of hardware + software together produces functionality

15. Proposed Model - Files
Representation of files within an archive file deliberately excluded.

16. Basic Software Model

17. Software Model with VM/VMM

18. Proposed Model – Linking into the CIM Core
PC unlikely to be directly Hardware related. FC, FD & LTP are more likely to be directly hardware related, but they would be best linked via CD anyway.

19. Example 1 – Eclipse
= conceptual starting point

20. Example 2 - Java

21. Example 3 – Routing ‘Process’ on a Router

22. Example 4 – Simple Host with Host Os Vmm
(because Storage not modelled)

23. Example 5 – CPU, Memory & Storage
Other software classes link in as per Ex-4

24. Example 6 – Blade Server Cluster
Or we could link the CD to both blades
Other software classes link in as per Ex-4

25. Example 7 – FPGA
FPGA may be FRU or non-FRU and this has no impact on the logical side of the model

26. Open vSwitch http://openvswitch.org/ (Slightly redrawn for clarity)
Diagram from
Table
Purpose
Open_vSwitch
Configuration for an Open vSwitch daemon. There must be exactly one record in the Open_vSwitch table
Bridge
Configuration for a bridge within an Open_vSwitch.
A Bridge record represents an Ethernet switch with one or more ‘‘ports,’’ which are the Port records pointed to by the Bridge’s ports column.
Software Process
ProcessingConstruct

27. Example 8 – Open vSwitch

28. Remove Before Publishing

29. TR-512.11_v1.3_OnfCoreIm-ProcessingConstruct.docx, Fig 3-3
? – do via FD
CdRepresentsEqBoundary
0..1
0..1
FdConstrainsFc *
Asymmetric
Asymmetric
Asymmetric
0..1
Symmetric
Symmetric
Symmetric