You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Status ONAP Frankfurt: UX Inventory

Topics of the change

  • EXTENSION of ONAP Frankfurt app ... by adding an additional treeview.
    • The existing functionality like Table and Export should remain as they are.

Topics of extension

  • Inventory view with two "folders" "Tableview","Treeview"
    • From ConnectApp the "Menue"-entry forwards to "Treeview" with DeviceId
    • Selction of app from right menue bar opens the "Tableview"
    • Tableview contains "Frankfurt"-view, including export function
    • Treeview does not support export
  • PNF Hardware inventory treeview, showing inventory hierarchy
    • Nodes are Subrack, Shelf, Card, Slot
  • Extension with additional view of "ODLUX Inventory app"
  • Planned for standards
    • ONF Core 1.2
    • IETF-hardware
    • O-RAN Fronthaul to be analysed
  • Metamodel "inventory" required
    • that bases on internal SDN-R data-provider model 
    • to be extended with 
      • levels
      • nodes
      • node types (Where is the rack, where the card)
  • Development against NTSim
    • Extension SDN-R data-provider inventory model

Open

How to map to internal model?

In ONF Core 1.2

  • Equipment specified that contains 0-N Equipment.
  • The fields for equipping are mainly text fields with dates, inventory and ordering numbers.

Mapping ?

  • There is no formal specification about the "nature" of the equipment ... is it a single card device or a Router with shelf, containing card, containing modules.
    {Martin Skorupski] the parent/child association is done by pointing from "holder" to "equipment" using the "occupied-field-replacable-unit (FRU)". The "nature" is given by the vendor in the "manufacture" area. Its values are vendor-specific and due to disaggregation (and re-aggregation) there is not and must not be a kind of standard "nature" - The "nature" of a network function can be exposed from the exposed APIs, but how this maps to equipment is room for innovation and unknown to generic implementations of ONAP.

  • The mapping can take place by knowing about "textual" keywords or "inventory numbers"-logics of manufacturers
    {Martin Skorupski] correct! - it is equipment/vendor/operator specific - 
    For ietf-hardware (as used by O-RAN Fronthaul please see "iana-hardware" - each NetConf server can define its "nature" (e.g Chassi, Backplane, SFP, ...)
    Please use https://www.iana.org/assignments/iana-hardware/iana-hardware.xhtml for the identification of the "nature".



  • No labels