Child pages
  • 2020-02-18 TAPI Meeting notes - Long Call - 3rd part
Skip to end of metadata
Go to start of metadata




Discussion items

25 minsAdministrative
15 mins

Brief overview of  otcc2020.ND.004_TAPI-ThoughtsOnTapiApplication.pptx

Nigel Davis presents some clarifications regarding:

  • TAPI general properties / assumptions
    • The client has one or more representations of the semantics (models) of the network
    • The client maintains a view of the instances of things in the network in each of its representational forms
    • The client has mapping rules to derive each of its representation of semantics from the TAPI interface representation
    • As a consequence the TAPI server aims to optimise the process of maintaining alignment for the client
    • What the TAPI server is not:
      • A database supporting random queries and joins
      • A GUI server
  • The definition of Top Level Connection of a ConnectivityService
    • Brief discussion on "Infrastructure Trail". Agreed that it can be a Top Connection in case SIPs are available to provision the related ConnectivityService (Infrastructure As A Service). If SIPs are not available, the Infrastructure Trail is a Connection (e.g. ODUk) created as result of the provisioning of client layer ConnectivityService (e.g. DSR).
  • Layering & partitioning
  • Action all to review the proposal.
15 mins

Brief overview of otcc2020.ND.003_TAPI-ProposedEquipmentModelAdjustments.docx

Nigel Davis presents a generalization of the relationship between AccessPort, Connector and Pin.

  • Currently AccessPort provides relates to one or more pins. The relationship is via connectorPin which is of type ConnectorPinAddress. Through this the AccessPort can relate to multiple connectors/pins.
  • Currently ConnectorPinAddress provides an opportunity to reference one whole connector or a single pin in a connector. If a whole connector is referenced, then it is assumed that all pins are used. If several but not all pins from a connector are used then the structure repeats the connector name and equipment UUID. The pin is referenced by a single pinIdentification.

  • An enhancement to ConnectorPinAddress to add an attribute “pinAndRole” (a list) is proposed for TAPI 2.3
  • The proposed change allows a single connectorPin property in an access port to reference a list of pins. This means that if several pins are used in the same connector, they can be collected in the same connectorPin reference.

    The new attribute is of type PinAndRole. PinAndRole offers greater clarity in terms of pin properties. The key properties are:

    • locationInConnector: Providing clear pin referencing so as to relate to the name of the actual pin in the physical connector.
    • pinName: Where the pin in the connector has a distinct name not merged into the location identifier
    • pinRole: Which allows the referenced pin to be tied to a specific functional detail in the NEP referencing the AccessPort. As noted in the description, there may be several pinRoles.
  • Action all to review the proposal.
60 mins


Continued from 2020-02-06 TAPI Meeting notes - Long Call - 2nd part

OMS model, the management of unidirectional and bidirectional OMS entities

Arturo Mayoral presents the figures related to unidir/bidir OMS model:

  • Agreed that path computation shall manage the co-routing of the two directions, i.e. in general the "unidirectional" model delegates the bidirectional management aspects to client controller.
  • After long and detailed discussion, confirmed the three scenarios agreed on 2020-02-06 TAPI Meeting notes - Long Call - 2nd part, copied below:
    1. Fully Unidirectional: Unidirectional SIPs (4-ended bidirectional ConnectivityService, i.e. also CSEPs are unidir)
      1. All internal NEPs and Links are unidirectional
      2. Supporting Top Level Connections are unidirectional
    2. Mixed: Bidirectional SIP and unidirectional internal NEPs and Links
      1. Supporting Top Level Connection is bidirectional
    3. Fullly Bidirectional
  • Agreed that the fully unidirectional model applies only for disaggregated scenario.
    • This implies that the Link between Transponder and OLP/ROADM is locally managed by orchestrator and there is no need to provide a model for it - which would be a three ended Link, connecting the bidir NEP of the Transponder with the two unidir NEPs of OLP/ROADM.
    • In other words, the integrated scenario always foresees either the fully bidir or the mixed case.
60 mins18OLP model

OLP protection between Transponder and ROADM:

  • Agreed that OLP model is fully unidirectional if ROADM model is fully unidirectional (case 1. above)
    • Even if due to its function, the bidirectionality should clearly emerge
  • Agreed that "Mixed scenario" (case 2. above) does not apply to OLP itself:
    • Bidir OLP NEPs are connected by a bidirectional Link to bidir ROADM NEPs
      • ROADM can be either fully bidir or mixed
    • Unidir OLP NEPs are connected by unidirectional Links to unidir ROADM NEPs
      • ROADM is fully unidir 
  • Agreed that NEP, CEP and Connection of the OLP are at PHOTONIC_MEDIA layer, with no qualifier (former OMS/OTS, see below) or NMC qualifier.

OLP protection between ROADM ("section" protection):

  • Fully unidir or bidir model, according to ROADM model
  • Agreed to represent the NMC "reliable" Link and the OMS "protected" Connection.

OLP protection external to managed network (client side OLP): agreed to remove the scenario from the document.

60 mins19OMS, OTS
  • After long and detailed discussion, agreed that OMS and OTS terms relate to monitoring scope, hence the topological model can be simplified using only NEP and CEP at PHOTONIC_MEDIA layer protocol name, without specifying (post meeting note, we need to add "UNSPECIFIED" value to LayerProtocolQualifier) the layer protocol qualifier. OTS and OMS monitoring capabilities will be modeled by two dedicated packages of photonic CEP. The presence of these packages will indicate the OTS / OMS monitoring span (and the presence of amplifier). 
    • post meeting note 1: monitoring direction is assumed only "co-directional".
    • post meeting note 2: in case of unidirectional CEP, evaluate whether to split packages into "sink" and "source" parts.

90 mins20Photonic forwarding model (NMC, SMC etc.)
  • Long and detailed discussion on Transitional Link between "electrical" and "photonic" Nodes.
  • Eventually agreed that Transitional Link in TAPI adds complexity rather than value. Agreed that Transitional Link is useful only for Path Computation.
  • Andrea Mazzini shows this slide to help discussion, but no agreement e.g. whether the Transitional Links shall include adaptation functions.

  • Agreed that FEC parameters will be moved from OTSiA CEP to ODU CEP.
  • Agreed that any parameter related to "inverse mux" of OTSi shall be placed in the ODU CEP.
  • Agreed that OTSiA CEP will be removed and replaced by proper MEP/MIP extensions, as shown below (for further refinement).
    • post meeting note, check ODU/OTU layers. In the figure below, shall we need the OTU CEP and NEP?
  • Concerning NMCA CEP in figure above, agreed to add an intermediate ROADM Node, to visually check "assembly" model.

  • Agreed that OTSiA ConnectivityService correspond to OTSiMCA ConnectivityService in the OLS domain.
  • Andrea Mazzini presents:

  • Malcolm Bettssuggests that even in integrated scenario, the OTSiMCA ConnectivityService should be explicitly provisioned. This to avoid overloading OTSiA ConnectivityService request with parameters of OTSiMCA.
  • Transponder and ROADM model related discussion will continue on next call.

Action items