Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2019-09-18 WT Meeting Notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Continue discussion on AirLink model

Discussion items

TimeItemWhoNotes
1Air Linkteam

  • Respect to the discussion held during the last meeting the following notes/questions apply:

    • defining parameters inside the AirLink does not mean to remove from AirInterface. the reason is that the node has to keep information and persistency of these parameters.
    • General question/doubt: the same model used in the context of southbound and as internal model of the SDN controller has no drawbacks ?
  • Next steps needed for model definition:
    • define network scenarios / use cases.
      • for example: when AirLink is created ? When AirInterface for the two network elements are created/configured. Probably it is needed to discover or associate to AirLink the two ends AirInterface with some checks on the fact that the two AirInterface are related to network elements working on the two sides of the AirLink,
      • Offline configuration needed ? (it is the possibility to create AirLink inside SDN Controller before connecting the SDN Controller to the network.
      • Discovery for Radio Link is not automatic if the ID is not unique in the network. This has to be considered.
    • define needed parameters for the AirLink and verify the use cases.
    • define the model via AirLink and ForwardingDomain / ForwardingConstruct 
      • We could check also how in the optical domain how is modelled the physical connection at optical level (connectivity between two adjacent nodes).
 2 General team Verify in the SDN Architectures if the SDN Controller is considered to have a database (so persistency) or not, in particular checking ODL and ONAP implementation as reference.

Action items

  •