Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Child pages
  • 2021-02-04 OIMT Meeting notes




  • Administrative
  • Media Channel: Multi-source/destination Media channel representation
  • Core control model (CD & Exposure Context)
  • Equipment model

Discussion items







Wiki pages have been updated

  • All the OIMT minutes were moved to OIMT minutes and organized by year (at the left sidebar)
  • Broken links have been corrected.

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 BettsWrite 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)
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

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 https://wiki.opennetworking.org/download/attachments/266141701/MapperPattern.pptx?api=v2
  • 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
Equipment modelLeo

How equipment type attributes are recorded

  • TR-512.6 Fig. 3-4 Equipment Detail Structure
  • Discussed how the equipment type attributes are recorded so that to avoid redundant and conflicting information in the model
    • Should ManufacturedThing be in EquipmentType instead?
    • Should the Equipment directly contained properties physical, mechanical, & environmental characteristics be EuipmentType instead?
    • Shouldn't the equipment category (EuipmentCategory: rack/shelf/...) be set by the EuipmentType?
    • ...

Next calls

 Report on the progress of

  • The writeup on multi-point MC restriction/rules 
  • Control model

Action items