Child pages
  • 2021-02-25 OIMT Meeting notes
Skip to end of metadata
Go to start of metadata




  • Administrative - CLA
  • Temporal expression (lifecycle state)
  • Equipment & Equipment type
  • Control model - C/S/A contexts
  • Review the writeup on multi-point MC restriction/rules (not discussed)

Discussion items





5 min


Contributor License Agreement (CLA) for contribution to OIMT. Within the OIMT project, the CLA covers contributions to the following repositories

Time of OIMT weekly call

  • Starting from March 11, OIMT call will resume the IM-D time, i.e., 0300-0400 Pacific Time 
15 minTemporal expressionChris

Temporal expression

  • ONF_T73_TemporalExpression.pptx
    • Reworked on the old Temporal Expression model by using the aggregation (wrapper) approach
    • The resulting model
      • The <<Agg_Root>>TemporalExpression can be reused via referencing
        • Recursive referencing to support/build complex cases, e.g.,
  • Malcolm noted that Lifecycle state needs only simple temporal expression 
  • Nigel noted that Temporal expression will be included in the core model
25 min

Equipment & Equipment type


Equipment & Equipment type model oimt2021.LN.001-Equipment Type model.pptx

  • Issues with the current model (TR-512 v1.4)
    • Many invariant per-type attributes directly under instance.
    • EquipmentType is an owned class (under ManufacturingThing), causing dupliction of identical information
    • Future TBD work and needed cleanup
  • Proposals
    • Group all invariant per-type attributes under EquipmentType
    • EquipmentType be an independent global class
    • ManufacturedThing split or remove
    • Improvements
    • Enhancement
    • Holder
    • Cable
  • Nigel noted that invariant per type & type attributes will go into the spec model
  • Will look into the proposal and rework on the model
  • Leo will make proposal in UML form
15 minControl 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

2021.02.04 brief discussion

  • Change View Mapping Function (VMF) to View Transformation Function (VTF), which might include functions, in addition to name mapping, abstraction, merging, partitioning, order rearranging, etc.
  • Mapping pattern
  • To label the CD instances with distinct numbers.
  • The CDs contain/group the resources.
  • Need an overall CD 
    • (see Malcolm's figure of last week)
  • Malcolm & Nigel to brainstorm on: List the things that VTF can do; Pattern; many-1, 1-many

2021.02.25 Clarification on the modeling of contexts (Client/Server/Administrative)

0 min

Media Channel


Multi-pointed Media Channels: Multi-source multi-destination 

2021.01.21 discussion

  • TR-512.A.4 Figure 4-28
    •  Representation of topology and frequency slot occupancy
  • Agree to use the Bidirectional overlaid trees approach to tackle the issue
    • Nigel Davis Start to draw simple single tree, find minimal forms, then draw the overlaid 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 overlaid trees
    • Might waste wavelenth

2021.02.04 brief discussion

  • Simple tree structure to evaluate network blocking
  • Build tree structure for each of the points (Transponders or ROADMs), then use overlay tree to evaluate blocking.
    • For each of the originating points (e.g., A, B, C, D, etc.), build a transmit tree through the intermedate coupler/splitter nodes to the end points (i.e., A-; A-;  etc.), then look at the overlapping segments (e.g., 2.3) of the overlaid trees (e.g., A- and C-2.3-G).
    • Identify the disjoint trees (e.g, B and C)
  • Nigel Davis Malcolm Betts Write text to explain the restriction and rules for bi/uni-directional for evaluating network blocking. Aim for adding to TR-512.A.4 (section 4.4.9)

2021.02.xx Review of writeup on multi-point MC restriction/rules

minLifecycle StateMalcolm

Status and workplan

  • Status recep
  • There is request to discuss how to use the lifecycleState model for network inventory.  
    • For example, how to add the time that something is planned to be added or removed.
      • One-time event
    • There is the Tempoal expression model.
      • It covers repetition. Could degenerate to one-time 
    • Keep track of the time of event 
      • Use notification and streaming
    • How to use the UUID, e.g., 
      • Equipment Holder and the contained Equipment, which could be one (the current one in the holder) or multiple (0..* for the planned/potential ones)
    • Mixing of lifecycle and ownership

Restructure of the document TR-512.3

  • Revised TR-512.3 to move out the lifecycle state material
  • Have a separate document, TR-512.17 (new) for lifecycle state. Yet to be agreed.
0 minNext calls


  • Review of writeup on multi-point MC restriction/rules
  • Lifecycle versus ownership

Action items