Child pages
  • 2018 March 12 - 16 OIMT & OTCC Interim Meeting Minutes
Skip to end of metadata
Go to start of metadata


12 - 16 March 2018



Discussion Items




 UML Modeling GuidelinesBernd

Draft IISOMI-514 "UML Modeling Guidelines v1.3.05"

  • Figure 4.1: Specification Architecture updated.
  • Conditional Specify/Augment mapping example added.
  • Core and Implementation CommonDataTypes added.
  • Bit encoding for Enumerations added.
  • Possibility to add an integer value to an Enumeration literal added.
  • Justification for UML package structure added in section 7.2.2.

Draft IISOM-515 "Papyrus Guidelines v1.3.05"

  • Warning added to not use the “update” menu.
  • Justification for UML package structure added in section 7.4.5.

Discussion topics

  • Header information: Where do we put Copyright/license information in UML etc
    • Input documents:
    • Discussed header information
      • Proposal for NameSpace from discussion:
        • urn:{sdo}:{project}:{sub-project}:{protocol}:{module}
        • Examples:
          • urn:onf:otcc:{tapi|wt|wr|...}:{yang|openapi|protobuf}:{moduleName}
          • urn:onf:otcc:tapi:yang:common
          • urn:onf:otcc:tapi:yang:connectivity
          • urn:onf:
        • Action item - Bernd: Take TD198/WP3 and re-formulate it into an ONF version for requesting an URN node from IANA for ONF
        • Action item - Kam/Nigel: Submit to Timon & Cassandra, cc the other project; mention the term "Secretariet" needs an appropriate replacement term.
      • Proposal for header information in UML
        • Put in the Stererotype for OpenModelStatement, including the following mandatory information elements
          • Namespace,
          • Organization,
          • version,
          • copyright,
          • license,
          • contact (static role)
            • Action item - Kam: ask Cassandra to create (sub-)project lead email addresses:
              • OIMT, OTCC, TAPI, WT, OTIM, DMIP
              • (In progress)
          • description (1 line)
          • Revision: multiple, these describe the change history from version to version, not YANG specific, including
            • date,
            • description (link to the github UML change log),
            • references)
      • Is the
      • Automatic generation and any additional manual changes to the YANG
  • oimt2018.ND.002.00_UmlModeling
    • Complex constraints and dependencies
      • Use OCL
      • Will define some default OCL statements for the common constraint patterns
      • Common constraint patterns
        • Loop
        • Spiral
        • Eight (Loop and Spiral)
        • attribute a and attribute b of same value
        • attribute a and attribute b of different value
    • Associations
      • General support on
        • Using OCL in constraint statements
    • Atomic/Composite vs Component/System
      • No conclusion on the Component/System pattern
      • Need to strengthen the argument of the Component/System pattern

Deferred to a later discussion:

  • Complex constraints and dependencies… State requirements etc (and perhaps discuss OCL and need for DSLs)?
  • Bidirectional associations and redundant associations (in context of the roles of the models)
  • Association classes (including Nigel’s document on associations)
  • Decorator
 TOSCA feedbackNigel
  • oimt2018.ND.003.00_ToscaFeedback
    • Relates to OCL and constraints work
    • Some discussion on whether it is really the hyperedge or the node that decomposes into further hypergraphs
      • The underlying consideration is that there is only a need for instances of one generalized type of complexity with touch points (zero dimensional interfaces) to other instances of the generalized complexity type
      • In a graph or hypergraph, the edge or hyperedge has dimension and complexity (e.g. directedness) and the node does not. Complexity has dimension. Most appropriate compacting is of node, not edge.
      • The hyperedge represents all complex things (functions etc) and the node materializes. The edge gains opportunities to form interfaces with other edges (as explained in TR-512.A.2.
    • If we relate TOSCA Node to Component then a distinction between the TOSCA metamodel and the Component-System pattern is the emphasis in TOSCA on the relationship between components and in Component-System the potential to form relationships via ports
      • The scheme (system) spec seems to relate strongly to the Tosca Topology template
 Temination model & Transitional LinkKarthik/Andrea




  • High-level updates of TAPI
    • TAPI Overview:
    • To apply TAPI for south bound interface to the devices, some functinality is still yet to be defined. No specific plan yet. Need driver
    • Comment (Thorsten): Even in heirarchy control (domain/vendor controllers),the control should be open control, not closed controller, otherwise erroneous configuration will cause huge problem and hard to be discovered.
    • ODTN
      • Main focus is mapping between the NBI TAPI and the SBI OpenConfig
      • ODTN Phase 1 covers only terminal device (Transponder) configuration
      • ODTN Phase 1.5 Architecture basically is the black link approach;
      • The Core model could also be applied
        • It is protocol neutrol and can be translated into specific interface protocols (such as TAPI or OpenConfig).
        • It is recursive and applicable at the NBI and SBI levels
      • The key is consistent control/configuration of the parameters in the devices across the OLS.
        • Need ONF and ITU-T SG15 collaboration.
  • High-level update of WT, including 5th PoC: WT Activities.pptx
    • Action item: provide link of the slides
      • DONE
    • WT 4th PTP took the IETF PTP YANG (1588 version 1) augment to the WT model
    • Need to improve liaisons with other SDOs:
      • With 3GPP SA5, in particular considering its 5G work
    • Action item Giorgio Cazzaniga: develop a slide to be presented by ONF at the ONS, regarding the 5th PoC
    • Touch point models:
      • Sync management, Ethernet managemetn, client control, 3GPP RAN LAN, (SG15 ), 3GPP sliding, BBF (has liaise with 3GPP SA5) on access wireline/wireless/PON,
  • Documentation of deprecation & obsolete (Nigel)
  • Topics covered: Lifecycle compatibility, tooling and translation, and tooling version changes
    • Action - Nigel Davis: provide slides - Done (link above)
    • Topics covered Lifecycle compatibility, tooling and translation, and tooling version changes
    • Action item: Nigel Davis / Martin Skorupski: (1) Need to state the vision of interoperability for lifecycle compatibility, (2) Then document in interpretable steps for both the model and interface.
    • Future work: Model changes need to be documented formally in machine interpretable manner. The owner SDO should provide the translator, which will be used by the client and/or server of the interface at run time.
    • Action item:  Nigel Davis: Need to sketch out machine interpretable migration mapping for UML models.
  • Sync-mgmt model
    • Liaised ITU-T draft new Recommendation G.sync-mgmt: oimt2018.LS.006.00_g.sync-mgmt_v0.05
    • Review comments (reference diagram: Synchronization-ClockContext)
      • Reuse the Clock class from the Core Model
      • Remove the clockSpec association to NE
      • Reverse the direction of the spec association between Clock and ClockSpec
      • Move the ptpSync and -phyLayerFrequncySync_Pac to the Pac of the ClockSpec
      • Compare the current list of attributes of Clock in G.sync-mgmt with the Core
      • Action item:  Nigel Davis: Agreed to make the following changes in Core model: (Done)
        • change "1 LtpIncludeClock" to "0..1 LtpIncludeClock" (Done)
        • change association name clockFeedsLtp to ClockDirectlyAssociatedWithLtp (Done)
        • change "_outLtp" to "_syncLtp" (Done)
        • Incorporate the ClockSpec class into the Core Model (Done)
          • Note that clock encompasses clock is specified by ClockSpec refers to ClockSpec
      • Action item:  Nigel Davis: Enhance documentation to explain ClockSpec (in progress)
      • Should add the condition for the conditional Pacs
      • Should treat PTP, SyncEth (base and extended are treated as one LP name with varieties) SyncO, etc., as distinct LpNames
      • Request Q14/15 to provide example diagrams in G.7711 form (e.g., multi-layer LTP instance supporting multiple LPs, including PTP and SyncEth) to ONF for use in a TR-512.A.8
    • On the issues raised by Q14/15,
      • Agreed that SyncTermination_Pac specifies LayerProtocol directly, no need to through LpSpec and TerminationSpec
 TR-512 v1.5Nigel (Ad-hoc)
  • Functional Protection (CC etc.) oimt2018.ND.005.00_FunctionProtection
    • Illustrated applying the Component-System pattern to describe a resilience component, which is resilence system encompasses of resilence and control etc. components.
      • discussed in small group then re-discussed on Friday
    • Essential representation shows that:
      • A ControlConstruct is realized by several ControlConstructs at a more detailed level where the behavior of the detailed ControlConstructs is such as to provide the manifestation of the one ControlConstruct to a user. This is the functional Component-System pattern.
        • Arc and Ar provide functionality that makes the user perceive component A, i.e. the outer ports of Arc and Ar appear to belong to component A
    • It was noted that the common port of Ar could be realized on the same platform as the user of A such that solution is resilient right up to the user
    • Components Ac and A+ are not visible to the user
    • The administrator can simultaneously view from both viewpoints, i.e. the user viewpoint of Component A and the viewpoint with the System of components Arc, Ar, Ac and A+



Control domain, Control Constructs, Peer-to-Peer control,Chris/Nigel/Malcolm
  • oimt2018.ND.006.00_ControlModel
    • Discussed the name of the term ConstraintDomain whether should be just Domain. Decided to keep the term ConstraintDomain.
    • It is a collection of stuff.
    • It could have null constraint
    • It describe the type of the role.
    • Action item:  Nigel Davis:
      • Need to further investigate the recursive ControlConstructControlsControlConstructView
      • Need to further investigate the recursive ControlPort
  • oimt2018.MB.002.00.controler_model
    • Agreed that it is allowed for a ControlConstruct to have multipl ConstraintDomains
  • ONF_T2b_PC_ControlComponentV2.pptx
  • A ControlConstruct can have multiple ports.
  • The role of a port can change on per message.
  • Aim to have the control model (CC & CD) in v1.4 is adaquate for modeling the NE.
  • Aim to demonstrate in v1.5 applying how the control model to model SDN controller
  • Partitioning vs specialization
    • LTP, FC, ControlConstruct are partitioning from ProcessingConstruct. Not specialization of ProcessingConstruct.
 Entity LifecycleMalcolm
  • oimt2018.MB.001.00_draft-TR-512.3_v1.4.0
    • The figures need to be updated to align with the text, including the lifecycle of the states. There seems tool issue.
    • Promote to Mature: AdministrativState and OpeationalState and Stat_Pac
    • Delete AdministrativeControl
    • Deprecate ShuttingDown of AdminstrativeState, it will be replaced with the LifecycleState
    • Promote LifecycleState and the enum from experimentatl to preliminary
    • Action item - Malcolm Betts: Review the "Relationship between entities and abstraction" with the Sotware document.
    • PotentialAvailable and PotentialBusy are sub-states of Installed (or separate states) related to usage (whiich is not in the model, might worth to define it)
    • PendingRemoval is a substate of Install
    • Clariffication is needed in Figure 3-7. In Controller n+1, the green entity in the Server context is the Supporting Enity, and the green entity in the Client Context is the Dependent Entity
 OAM modelAndrea / Karthik

Karthik: TAPI OAM model sketch

Andrea: MEF NRM OAM 2.2

Discussion notes: See 2018-03-12 TAPI F2F Meeting Notes




Softeware document overview


Control model examples

  • Action item Malcolm Betts: To post the slides
  • To facilitate the discussion of the control model
  • All are valid
 Operations pattern & Control Construct modelNigel
  • Operations pattern model
    • oimt2018.ND.006.00_ControlModel-20180311
    • Verified the associations and cardinaity of the association ends between the model classes ConstraintDomain (formerly ControlSystemView), ControlConstruct, ControlPort, LTP, and ControlViewMapping
    • Significant time spent on the name of "ConstraintDomain". No conclusion.
    • Agreed on a problem statement.
    • Problem statement: How to enforce the common association patterns in the specific models, such as forwarding, control, equipment (physical), software models etc.
 Spec modelsKarthik/Kam

Agenda and discussion notes: See TAPI 2018-03-12 TAPI F2F Meeting Notes



UML-YANG MappingBernd

Draft IISOMI-531 "UML-YANG Mapping Guidelines v1.1.06"

Main changes:

  • Figure 4.1: Specification Architecture updated.
  • Conditional Specify/Augment mapping example added in Table 5.16.
  • Identity naming rules updated for extendable enumerations in section 5.5.4.
  • Mapping of bit encoding for Enumerations added in Table 5.13.
  • Grammar definition of a YANG identifier added.
  • «LifecycleAggregate» Relationship Mapping Examples added in Table 5.14.

Discussion topics

  • Where does copyright etc info go in Yang
    • iisomi2018.BZ.003.03_YANG-ModuleHeaderInformation.docx
    • Diff-mark accepted
    • Discussed and agreed on the following UML model header information. Mapping of the UML model header information into YANG header information have also been taken into consideration
      • Version examples:
        • ONF Transport API version 2.0.1
        • ONF Wireless Transport PoC 5
        • ITU-T Rec G.8052 v2.05
      • Is the copyright and license statement of the UML model the same as for the YANG module?
        • Yes, it has to be
      • How to deal with YANG modules partly generated by the tool and partly manually? There is an optional field in the generated YANG, which allow people to manually add a warning text/note into that field.
      • How to ask the mapping tool to import YANG modules from other SDOs (e.g., import ietf-inet-types)?
      • Which input information takes precedence?
        • config.json takes precedence.
  • Tooling
    • Action item - Bernd Zeuner: to discuss the rules for Re-engineering YANG into UML
      • Types of artifacts need to be discussed:
        • Data types, etc.
      • Martin suggested map the YANG YIN (XML) to UML XMI
      • Action - Martin Skorupski: Take the XMI of ietf-inet.type and ietf-yang.type and map into UML xmi (in progress)
  • UML2YANG Mapping Tool Administration
    • New UML2YANG tool generates different YANG files compared to old version: #277  
  • YANG catalogue registration
  • leafref issue
  • Influence of NMDA
  • Administration on the mapping tool
    • Need Versioning of the tool
    • Enforce change control via the following hierarchy of roles
      • Administrator and Committers
 Spec modelsKarthik/Kam
  • OTSi Spec model for the OTSiG-O (OAM)
    • ITU-T G.798 OTSi and OTU MI signals: oimt2018.KL.003.02_OTSi-MI.docx
      • The G.798 OTS-O atomic function and its input & output MI signals were looked at to determine what need to be included in the OTSi model
        • Clarification of the notation being used for the MI (Management Information) signals in G.798
          • Take "OTS-O_TT_Sk_MI_cLOS-P" as an example
            • This is an MI signal listed in the "output" column of Table 9-2 "OTS-O_TT_Sk inputs and outputs" of G.798 (re-produced below)
            • The "OTS-O_TT_Sk_MI_cLOS-P" notation indicates that this is a management relation information reported by (i.e., "output" from) the OTS-O_TT_Sk atomic function (i.e., the OTS-O Trail Termination Sink function) acorss the MP (Management interface Point) to the EMF (Equipment Management Function) of the device about the raise of cLOS-P (i.e., Loss Of Signal - Payload fault cause). This cLOS-P fault cause is raised (reported) by the OTS-O_TT_Sk function against the OTS-OSME, which is being monitored at the monitor point "P" .
        • At OTS-O_TT_So, there is OTS-O_TT_So_DI_LOS-P input signal, but it seems missing output MI signal OTS-O_TT_So_MI_cLOS-P
  • Using the Media model for TAPI (Nigel)
    • Action item - Nigel Davis: post the slide deck Photonic.pptx (done oimt2018.ND.008.00_PhotonicModel-20180320.pptx)
    • TAPI needs: Frequency accounting (occupancy), frequency configuration, modulation, route of OTSi_A
    • Action itemKarthik Sethuraman: Send the TAPI diagram to Nigel for Nigel to integrate the TAPI diagram with the Media model diagram (in progress)
    • Action item - Nigel Davis: Combine photonics model and TAPI diagram into one figure.
 Resilience use cases for TAPIRod
  • otcc2018.Rod.003-TAPI_Resilience_use_case.v01
  • Reviewed the proposed modification to the draft of TAPI 2.0 FRD: TR-527-V2-DRAFT.docx
  • In 4.1.2, Add note to state that single domain e2e 1+1: switching is unidirectional switching
  • In 4.3.2, change "... request two independent ConnectivityServices" to "... request two related ConnectivityServices"
  • In 4.3.2, Trigger: delete mentioning of API
  • In 4.3.3, Connectivity Creation: Interdomain SIPs need to be provide by the MD Controller to the Domain Controller.
  • In 4.3.3, Retoration Trigger: Interdomain SIPs need to be provide by the MD Controller to the Domain Controller.
  • In 5, Update Service Type: use Template approach instead of Operation
  • Reason for using template approach:
    • Avoid repeating
    • Opaque template approach: only specific the template type
    • White box template approach: specific specific templates, which details the parameter combination
  • Action item - TAPI: TAPI to explore support the templating mechanism, allows generating template, no RPC,
  • Action item - Rod: To upate the use case document.
 Wrap upKam/Nigel
  • Liaisons
    • Action item Nigel Davis: Draft LSs to share the Control Model
      • To:
        • SG15 (as response)
        • ZSM (as response)
        • MEF
        • TOSCA
    • Action item Malcolm Betts: Draft LSs to share the media model
      • To:
        • SG15
        • MEF
    • Action item: Explore how to send liaison to ONAP or not

Action Items

  • Hing-Kam Lam: ask Cassandra to create email addresses for project-roles, project-editor-roles