Child pages
  • 2019-11-15 TAPI All-Day Virtual Meeting notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Topology (12:00 - 15:00 CET)
  • Connectivity (15:30 - 18:30 CET)

Discussion items

12:00-
14:30 CET

Topology 1Stephane St-Laurent

  • Slide 18, Case A and B, specify spectrum, Case A offset, Case B absolute value parameters, Case B is preferred one.

  • Model of unidirectional topology and connectivity: sink and source ancillary/specification classes, instantiated together in case the different directions share fate - realizing bidirectional object.
    • Currently in TAPI the photonic classes are bidirectional, to be decoupled.

  • Malcolm Betts recalls that Raman distributed amplification shall be considered.
    • Raman amplification can be represented through Forwarding together with Control Constructs. Agreed to postpone the detailed discussion.

  • Stephane St-Laurentshows in slide 30 that for the model of network forwarding is enough to stop at MC layer:


  • Slide 56, configuration of OTS, OMS and OSC:

  • Slide 57, Link provisioning
    • Top-down provisioning of "physical link", to build the network topology.
    • Stephane St-Laurent recalls that RFC 8345 already foresees the link and topology creation.
    • Karthik Sethuraman recalls that TAPI Virtual Network model was included for the purpose of overall top-down provisioning, hence including topology - but the current model needs further development.

 

  • Agreed that TAPI shall add "TopologyService", including "LinkService". Creation of Node and Node Edge Point postponed to future evaluation.
  • Agreed that once the bottom-most Link is provisioned, then ConnectivityService (hence its supported Link) can be recursively built on each layer - this is already in line with current TAPI definition.
  • All these ConnectivityServices are necessary for OAM provisioning.
    • Karthik Sethuraman recalls that OAM can be provisioned just on SIPs (UNIs, E/I-NNIs) since we made CSEPs optional according to MEF requirement ("port" monitoring). So ConnectivityServices are not strictly necessary for OAM provisioning in this scenario.
  • Slide 66 shows the case where the stack is built by server controller.
    • MEP/MIP can be pre-provisioned by server controller, nevertheless there could be the need of further provisioning:
      • Same as above, ConnectivityServices are not necessary, as long as a SIP is available - hence allowing OamService provisioning.

  • Slides 68, 69: domain boundary, single ended ENNI Link

 

  • Agreed that this applies also to UNI.
  • Considered the single ended ConnectivityServices ("towards the external") for Down MEP provisioning to monitor ENNI and UNI:
    • Same as above, ConnectivityServices are not necessary, as long as a SIP is available - hence allowing OamService provisioning.
    • Furthermore Karthik Sethuraman recalls that "open MEG" is already supported.
      • 1. ME may have 0 MEPs (case of transit domains where at least 1 MIP is present)

        2. ME may have 1 MEP (case of edge domain, where the peer MEP is ouside the managed domain)

        3. ME may have 2 MEPs

  • Andrea Mazzini recalls the "virtual NE" or "black box" etc. model, to support an end to "exiting" links and connections.
    • Agreed that the "black box" approach adds complexity.
  • Allow Link to have only one NEP.
  • Slide 73, Physical Layer can be used to represents the logical view of physical signal flow within the equipment.

 

  • Discussion on two-sided Connection End Point, which encapsulates a link connection which is not relevant for topology.
  • In general, there is a Forwarding Construct spanning the equipment, which may be partitioned in a number of lower level adjacent FCs, joined by two-sided Points which are relevant for OAM. The link connection is not encapsulated in case is supported by e.g. fibre/cable which may be broken/disconnected/misconnected etc, in other words when it is relevant for management.
  • Further analysis is necessary - introduction of a CEP which can end two Connections. Introduction of Link Connection?

14:30-
15:30 CET

Topology 2Andrea Mazzini
  • Andrea Mazzini presents otcc2019.AM.005_Photonic-OMS-OTS.pptx
    • Agreed that L and C bands always share fate
      • Nigel Davis, considering e.g. unidirectional connectivity, the pattern role is to model bidirectional entities in case of fate sharing, unidirectional otherwise.
      • Malcolm Betts, there are implementations where OAM is common for both L and C bands.
      • Stephane St-Laurent underlines that there could be two OSC channels for the same OTS
        • This could be represented by two MEP instances
    • Stephane St-Laurent points out that in photonic model, the agreed role of the Connection End Point is to represent continuous passband. Hence the distinct L and C band CEPs. In fact, all the model "hierarchy" concerns the selection of progressively narrower passband, starting from widest one (OTS) to narrowest one (OTSiMC). In fact e.g. MC CEP represents a subset of OMS band, but it is separately modeled.
    • Proposed model by Stephane St-Laurent:

  • Conclusions:
    • Nigel Davis , Malcolm Betts , Hing-Kam Lam and Andrea Mazzini agree that either representations are allowable, because TAPI implements abstraction and mapping, hence is difficult / not applicable a selection of only one abstraction.
      • Nigel Davis the full or extended view appears less efficient.
    • Arturo Mayoral agrees on the principle, but:
      • selecting only one solution would facilitate interoperability,
      • with a preference for a backward compatible solution.
    • Stephane St-Laurent prefers only extended view, with optional representation of OSC and PHY layers.
16:00-
18:30
CET
Connectivity

 

For each of the 4 use cases above Stephane St-Laurent presented resp. 7, 9, 8, 1 sub cases, three examples below:

  • There were no objections to all presented use cases ranging from "only bandwidth and offsets" to "exact spectrum frequencies", delegating or not delegating if and how to aggregate the OTSiMCs of the OTSiMCA in the MCs (e.g. the "express channel" case).
  • Note that non-adjacent-spectrum can be specified as "exactly equal" or "equal or greater" than a value.
  • Note the concept of  "add-drop shared", in case there are:
    • multiple interfaces between transponder and ROADM,
    • the OTSi supported over these multiple interfaces can be routed through shared spectrum (see slide above)
  • Note that all input parameters are moved to CSEPs, while the hierarchy is specified through the MC and OTSiMC "inner" ConnectivityServices.
  • Andrea Mazzini presents one slide from oimt2019.AM.001_TAPI PhotonicConnectivityModel.pptx where it is proposed a different structure for MCA and OTSiMCA provisioning, avoiding the introduction of OTSiMC and MC ConnectivityServices.
    • Proposed that ConnectionConstraint should be an augmentation of ConnectivityConstraints. Note that one instance of ConnectivityConstraint could refer to more instances of ConnectionConstraint.


  • Stephane St-Laurent confirms that the unique modeling solution fulfilling all presented and agreed use cases is to introduce a new hierarchical ConnectivityService type, which includes subordinate ConnectivityService items.
  • Arturo Mayoral agrees on the requirements, but recommend to explore alternative solutions which do not break backward compatibility.

  • Talking of ConnectionRoutingConstraint, brief detour on resiliency model. Discussed whether the Switch Control is similar to a Forwarding Domain, hence delimiting a (resiliency) Connection. If so, the various routes (in simplest case "main" and "spare" ones) have their reference Connection.
    • Further discussion postponed as scheduled time was over.

Post meeting noteAndrea Mazzini

This 6 hour session was a good compromise between sustainable remote call time and level of discussion detail.

Action items

  •