Skip to content

(TID) Network device inventory management

Proposers

  • Oscar González (TID)
  • Pablo Armingol (TID)
  • Juan Carlos Caja (TID)
  • Daniel King (ODC)
  • Lluis Gifre (CTTC) [reviewer]

Description

The proposed functionality is about retrieving the hardware (physical) inventory from the network devices, storing the information in TFS Controller. TFS will retrieves the list of components of each device using Netconf and OpenConfig data model [1] via the device driver.

For each router, the Hardware (HW) components to retrieve are:

  • CHASSIS: is the top level component and can be understood as the main device.
  • CPU: processing unit, e.g., a management processor.
  • FAN: cooling fan or some other heat-reduction component.
  • POWER_SUPPLY: component that is supplying power to the device.
  • FABRIC: interconnect between ingress and egress ports on the device (e.g., a crossbar switch).
  • CONTROLLER_CARD: a type of card whose primary role is management or control rather than data forwarding
  • LINECARD: component typically inserted into a chassis slot that provides interfaces to the network.
  • PORT: physical port, e.g., for attaching pluggables and networking cables. If the port mode is breakout, the component is composed of N ports (example: QSFP).
  • TRANSCEIVER: pluggable module present in a port.

The common information to store per components is:

  • Type of component as identified by the system.
  • Description: System-supplied description of the component
  • Location: System-supplied description of the location of the component within the system. This could be a bay position, slot number, socket location, etc. For component types that have an explicit slot-id attribute, such as linecards, the system should populate the more specific slot-id.
  • mfg-name: System-supplied identifier for the manufacturer of the component. This data is particularly useful when a component manufacturer is different than the overall device vendor.
  • mfg-date : System-supplied representation of the component's manufacturing date.
  • Hardware-version: For hardware components, this is the hardware revision of the component.
  • Firmware-version: For hardware components, this is the version of associated firmware that is running on the component, if applicable.
  • Software-version: For software components such as operating system or other software module, this is the version of the currently running software.
  • Serial-no: System-assigned serial number of the component.
  • Oper-status: If applicable, this reports the current operational status of the component. Options: ACTIVE, INACTIVE, DISABLED.
  • Parent: Reference to the name of the parent component. Note that this reference must be kept synchronized with the corresponding subcomponent reference from the parent component.
  • Available: The available memory physically installed, or logically allocated to the component.
  • Removable: If true, this component is removable or is a field replaceable unit

Demo or definition of done

  • Retrieve from at least 2 different network devices the OpenConfig platform components and parse them correctly.
  • Store in Context the list of components per device. For each component the type of component has to be stored and which are the child components.

References

  1. OpenConfig platform data model. https://openconfig.net/projects/models/schemadocs/jstree/openconfig-platform.html

Feature Design (for New-Features)

workflow 1. Collect information from one device in TFS

Workflow 2. Collect HW information from all devices in TFS

References

None

Assumptions

  • The network nodes that are part of the inventory have NetConf enabled and support OpenConfig platform model. The nodes can be IP/MPLS.
  • The network nodes are already onboarded in TFS and are already associated to the OpenConfig driver.

Impacted Components

Context, Device

Context component Impact

The Context data model needs to Update to accommodate a list of components per device. Each component, uniquely identified by an UUID will be stored in the database. Hence, the Component needs to be modeled.

The message to create / update a device needs to be extended to include the component list as shown below:

message Device {
  // ...
  // Used for inventory:
  map<string, Component> components = 8; // dict[comp.name => Component]
}

message Component {
  Uuid uuid = 1;
  string name = 2;
  string type = 3;
  repeated string child = 4; // list[sub-component.name]
  map<string, string> attributes = 5; // dict[attr.name => json.dumps(attr.value)]
}

Currently, field component is just a String.

Device component Impact

The Device component needs to collect the openconfig-platform information and send it to context upon request.

Testing

  • Collect information from one device in TFS
  • Show inventory information
Edited by Lluis Gifre Renom