Child pages
  • 2019-02-14 OIMT Meeting Notes

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.






IM-DMarch Sydney meetingAll

TR-512 v1.4.1 progress and Gendoc Issues
  • Nigel reported on the progress of
    • updating the model for v1.4.1 and
    • updating the core model equipment diagrams (TR-512.1 and .6) and then to make them in the TAPI form for moving into TAPI
    • Progress has been slow, mainly due to the Gendoc issues when using the Papyrus-2018.12 tool
    • He is exploring potential (tedious) work around method
    • Aim to have few more diagram in TR-512.2.
  • Papyrus issues with Gendoc
    • The Gendoc tool doesn't work well on the Core model when using Papyrus-2018.12
    • Fine with generating attribute tables
    • Has problem with generating diagrams, process hung! (Papyrus-2018.09 seems having a chance of generating something)
    • Chris suggested trying on a small model (TAPI or ITU-T models). Nigel has been trying on one diagram (i.e. removing all the other diagrams) and then bring the other diagrams back
    • Action - Scott Mansfield : will try on a smaill model (such as the G.8152 MPLS-TP model) using Papyrus-2018.12 using nightly Gendoc
    • Chris: Can we validate the diagram first - to make sure no corruption in the diagram
    • Nigel: First time clicking on an association (e.g., try to move the line around, not changing its annotations), it took long, long time to bring the association up. But from then on it was fine. Wonder there was association transformation taking place in the process in the meta model.
    • Nigel will try one one diagram, moving all the association lines around, and then generate/print the diagram in Gendoc
      • Create a simple diagram, can check the XMI to see if any change in the XMI due to the moving of the association line.

Model re-structure
  • Model structure refactoring for v1.5?
  • Nigel and Chris have explored
    • Decouple the models in the right way so that have some sensible heirarchy and dependency
    • Look at the associations to see if any of them need to be reversed. There are circular dependency (e.g., between Equipment and ProcessingConstruct). Need to revise the circular dependency into senisble heirarchy
    • Package structure, Chris is sketching a proposal.
      • Organize according to functions (e.g., CD).
      • TAPI is not in this way currently. Need to look into implication on TAPI and ITU-T.
      • Organize the diagrms into functional block
      • Folder/Package structure (currently classified according to class, association, ...)
      • Break down into CIM, TAPI, etc.;
        • Then into function blocks (instead of class, association, etc.), such a package for Forwarding Construct, ConstraintDomain, Network function, etc.
        • This is 2nd level down from the .x breakdown
      • Organize the diagrams into functional consideration
      • Have the right rules to follow
      • Implication on the UML guideline
      • Will discuss at the Sydney meeting

LTP Port
  • Chris: TMF TR215
    • FD and LTP Port, FC
    • Moving FD/CD/FC/...'s associations with LTP to with LTP Port

    • Should FD be treated as a type of CD?
      • From a particular perspective FD is a subtype of CD but FD has additional capabilities that CD doesn't have.
    • Malcolm: In ITU-T G.800 SubNetwork is constrainted by port, but port is then subsumed into the termination function. Should revisit this approach.
    • Explore the relationships among FD, FC, LTP and their ports
    • MB: FD can support multiple layers, but tackle single layer first
  • Nigel:

    • FD aggregate LTP Port, instead of aggregating LTP
    • Impact on Spec model
    • Impact on relationship between LpPort and LtpPort?
    • This is aim for version 2.0 for TR-512
    • Action - Nigel Davis: Should consider transitional link too
    • Action - Nigel Davis: Redraw the LTP diagrams to have with LtpPort in it.
    • 4 LTP optinos (screen shot)
    • Action - Nigel Davis: to post the slide

Virtual Network
  • Virtual Network from a Core perspective
    • Service-Resource -Capability and Intent
    • Stimilated by TAPI 2.1.1 Capacity/Use model work
    • Capacity/Potential – Virtual Network view
    • Use/Enable – Service view
  • Further discussion Next week