1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2020-12-02 5G-xHaul Meeting notes

00:00

2020-12-03 16:00 CET- 18:00 CET

Joint PoC "Proof of Concept" O-RAN/OSC/ONAP

ZOOM session: https://zoom.us/j/436210993;
Note that Zoom is being used to accommodate participants from O-RAN member companies who have LFN credentials but may not have (may not need) O-RAN Atlassian accounts.

O-RAN-SC: C-Release: https://wiki.o-ran-sc.org/x/D4w_AQ

Email by Thorsten

https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU

Creation of objects

S1 use case

• new VLAN must be configured
• VLAN FC needs to be created
• generation of IDs for local-ids and uuids
• Up to know the idea is that the Device is the master of object identification
  • main reason: mediator alignment/synchronization with the device
• Process
  • first LTP for VLANs must be created → with a given identifier
  • second FC for VLAN is created → with a given identifier

• minimum requirement for FC(VLAN)-uuids
  • unique within the ForwardingDomain(VLAN) device

• 3 proposals by E///
  • VLAN-ID → FC identifier
    • drawback - same id for different object times (not universal unique) - unique "only" per device/object-type
      • so not a big limitation
  • specific pattern for identifier values, to indicate that the server will later sign the final value
    • Example: :NEW:
    • NetConf client needs to accept in the response a different identifier at least must re-synch
    • Similar tasks expected for the NetConf Server
    • netconf:merge vs netconf:create
      • in both cases the identifier must be given
      • NetConf server will use the given identifier
        • seems to be impacting NetConf Server Platform implementations 
  • Define a specific VLAN-FC-Creation RPC → Action 
    • RPC for entire object creation (except the identifier)
      • Device can then define the final identifier
      • Object Creation Notification required for the VLAN-FC (as in all other cases too)
    • two procedures
      • create empty FC first, then add later the interfaces references
      • give interface reference as property to the creation RPC
      •  
    • Alternative: RPC to get the next valid identification value
      • function generateVlanFCuuid( parameter: vlanId )

new proposal by SIAE:

In order to provide to the application the "next" uuid an option could be the following:

1) Add in the model in the section "status" the "next-uuid" parameter

2) In case this "next-uuid" is influenced by some value: add in the section "configuration" the corresponding "influencer" values

i.e. with reference to the VLAN creation, in VlanFd we could have something like:

- In section "configuration": "next-vlan-fc-vlan-id"

- In section "status": "next-vlan-fc-uuid"

End of the meeting

Backlog

INFO: https://github.com/openBackhaul/core/wiki/summary-of-issues

Firmware

Use case discussion challenging the model proposal:

Please see updated slides (thanks Eduardo).

https://wiki.opennetworking.org/download/attachments/265093121/201102-TEF-working-document-FirmwareModeling.pptx?api=v2

Feedback from vendors:

• working assumption: (running) Firmware pointing to (actual) Equipment
  • assumption
    • 2 banks (logical structure of firmware)  
    • • on running bank → list of firmware
        • some of the unused → those wont have an associations to (actual) Equipment 
    • Question: is the "top-level" firmware a "bank"?
      • software packages → 1 and 2 → bank 1 and 2 → or active/inactive → top-level firmware.
      • Consideration: firmware without software package
• SIAE: option to implement in addition also pointer from Equipment to Firmware

Firmware inventory

• UML and yang creation 

Firmware operations

• download, activation, upgrade, downgrade
• terms and definitions, needed before UML and yang

As a result of the discussion about Firmware, their might be a need for a "restart" trigger.

The "software activation trigger" usually also leads to a "restart" but with new software, which a "restart" reboots using the currently running software.

Other terms for the same? or similar? function:

• cold start (Power down, power up; traffic loss for sure)
• warm start (restarting software - may have - may not have traffic loss)
• reboot - this term should not be used as it is not clearly defined/used
  
  
  
• (factory) reset (configuration is lost) - not a field/remote-controller operation → LCT operation → should not be covered in your API models

Questions:

• Is a "cold start/warm start" trigger beneficial on ControlConstruct level only?
• Is a "cold start/warm start" trigger beneficial on Equipment level only? There are devices offering such options:
• both?

General reboot

• cold start / warm start on device level

Questions:

• Are License be updated during life time of the device?
  • Answer: yes - there are such cases, particularity for feature enhancements or for later enabling a license - xPIC may come later, when the second link is deployed.
• Understanding association between License Firmware, LTP, Hardware, Features/Function?
• Do all devices require a license? 
• Is a "feature-key" a "License" - from functional point: yes
• What kind of License types needs to be supported - Software, Hardware, Interface, LTP, Capacity, Features, Function, ....
  • Frist idea: focus on interface-capabilities

First proposal:

• ControlConstruct
  • LicenseList
    • License
      • Name
      • Type
      • Description
      • key (value; hash to be checked against, ...)
      • additional-configuration - (e.g. max capacity is xyz MBit/s)
      • State: activated; expired, no-active, ....
      • pointing to "something"

2020-11-18

• further introduction of the last slide: https://wiki.opennetworking.org/download/attachments/265093121/201102-TEF-working-document-FirmwareModeling.pptx?api=v2
• collection of ideas / use cases driving a model are ongoing.

PureEthernetStructure, HybridMwStructure