Open Information Model & Tooling
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-01-28 OIMT Meeting notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Agenda

  • Use of the Core model
  • Media Channel: Multi-source/destination Media channel representation (Not discussed)
  • Core control model (CD & Exposure Context)

Discussion items

Time

Item

Who

Notes

IM-D


Use of the Core modelWayne

Use case:  An overarching common information model for network inventory applications

  • Scopes: Including
    • Physical structures (such as buildings, towers, equipment holders) 
    • Internal and Geographic Location
    • Physical Equipment and Holders
    • Network
    • Software
    • Cloud
  • Observation on using the ONF core model
    • Associations that appear to be reversed.
    • No ITU-T equivalent of a Referent Point.
    • Rationale of Ltp Port
      • Strand
    • Is there a pattern for defining “constraints” in constraint domains, and specifications?
    • Any thought given to network naming hierarchies / conventions?
      • TMF TR224, ID (e.g, UUID) and alias names;
      • ONF TR-512.3
    • Model extension
      • Experimental and preliminary statuses.

Media Channel

Nigel

Multi-pointed Media Channels: Multi-source multi-destination (Not discussed)

  • TR-512.A.4 Figure 4-28
    •  Representation of topology and frequency slot occupancy
  • Agree to use the Bidirectional overlay trees approach to tackle the issue
    • Nigel Davis Start to draw simple single tree, find minimal forms, then draw the overlay tree, then use in both TAPI and Core 

  • Pattern of simple tree (non-intersecting)
    • Primitives: Merge (M) / Split (S)
    • n nodes: 2**n options
      • e.g., 2 nodes: 2**2=4 options: MM, MS, SM, SS
  • Pattern of overlay trees
    • Might waste wavelenth
Control modelKam

Clarification on the control model needed by ITU-T Q14/15

  • Clarification from the 2020.12.10 discussion on ExposureContext (EC), ConstriantDomain (CD), ControlConstruct (CC), ControlPort (CP)
    • The relationship among EC, CP, and CD:  
      • The client talks to EC through CP about CD.
    • EC: The "How". The gateway/agent for accessing. It defines the rule/requirement of accessing.
    • CD: The "What". The thing to be viewed by the client in the CPI (control plane interface)
    • CC/CP: The "Where". The interface port to access the CE.
    • In the current v1.4 UML, the ControlConstructExposesExposureContext association should be ControlConstructAccessesExposureContext    
    • One Vmf can provide multiple views from the same set of resource.
    • An ExposureContext can only expose one highest level (most outer) ConstraintDomain,
  • Additional clarification on 2021.01.21
    • The model allows access to multiple ExposureContext from a single ControlPort. For example, to support multiple users/applications at the same CPI (control plane interface) ControlPort.
    • Consideration of multiple ControlPort vs multiple ExposureContext
      • High-level security control and coarse grain operation control are set at the ControlPort. 
        • Additional ControlPort instances could be instantiated to meet different security requirements or operation previlage. 
      • Fine grain control (e.g., at object/attribute level) are set at the ExposureContext 
  • Additional clarification for TR-512.8 is needed.
    • Lifecycle of EC and its dependency on CD
    • Additional associations 
    • Multiplicity
  • Start up bootstrap:
    • CD representing the controller
      • Then administrator create ....
    • 2021.01.28 discussion
      • Malcolm's sharing
        • Discussion:
          • Client cannot see all things in the CD for the client context (CC), such as the resource allocation, view mapping 
          • Exposure Context 1 (EC1) and EC2 and their contained CDs reveal the view 1 and view 2 to the client
          • Note that Exposure Context 1 (EC1) and EC2 extend beyond the Controller CD.
            • For dealing with the communication infrastruture.
            • Need to look at the CD and EC for managing the communication infrastructure
            • Control of the control infrastructure 
        • Questions:
          • Is security an implicit part of the Exposure Context (EC)?
          • Do we need an explicit Controller Admin EC?
            • Or do e allow the Control Construct in the Admin CD to directly access all resources in the Controller?
          • View Mapping
            • Single or One per view ...
            • ...
          • Need to think about the implications on the server context (in the client controller) when multiple views are provided
      • Nigel's sharing
      • Bootstrap steps: Controller / What it will control / name translation between Server context and local context / create client context for the client to use the resource / 
        • Could one builds VN (for client) with planned resources?
        • Is name mapping part of view mapping?
        • Name translations: IN from the south (server), OUT to the north (client)
        • View in the same namespace and view in different namespace
      • Aspects: (1) Bootstrap, (2) Create/maintain/modify client contexts, (3) Attach the controller to the comms infrastructure
        • View mapping in the local space (Abstraction/refactoring), Name translations (from south to local, from local to north), , 
      • Resources from planning to deployment
        • Need the temporal model
Next calls

 : Control model, Media channel, 



Action items

  •